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ABSTRACT 


This  thesis  provides  a  performance  evaluation  of  the  IRIDIUM®  Low  Earth  Orbit 
Satellite  system.  It  examines  the  system's  ability  to  meet  real-time  communications 
constraints  with  a  degraded  satellite  constellation.  The  analysis  is  conducted  via 
computer  simulation.  The  simulation  is  run  at  low,  medium  and  high  loading  levels  with 
both  uniform  and  non-uniform  traffic  distributions.  An  algorithmic  approach  is  used  to 
select  critical  satellites  to  remove  from  the  constellation.  Each  combination  of  loading 
level  and  traffic  distribution  is  analyzed  with  zero,  three,  five,  and  seven  non-operational 
satellites.  The  measured  outputs  are  end-to-end  packet  delay  and  packet  rejection  rate. 
In  addition  to  the  delay  analysis,  a  user's  ability  to  access  the  network  with  a  degraded 
satellite  constellation  is  evaluated.  The  average  number  of  visible  satellites,  cumulative 
outage  time,  and  maximum  continuous  outage  time  are  analyzed  for  both  an  Equatorial 
city  and  a  North  American  city.  The  results  demonstrate  that  the  IRIDIUM®  network  is 
capable  of  meeting  real-time  communication  requirements  with  several  non-operational 
satellites.  Both  the  high  loading  level  and  the  non-uniform  traffic  distribution  have  a 
significant  effect  on  the  network's  performance.  The  analysis  of  both  network  delay 
performance  and  network  access  provides  a  good  measure  of  the  overall  network 
performance  with  a  degraded  satellite  constellation. 
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CHAPTER  1 


INTRODUCTION 

1.1  Research  Goal 

The  goal  of  this  research  is  to  assess  the  IRIDIUM®  Low  Earth  Orbit  (LEO) 
satellite  network's  capability  to  provide  real-time  communications  with  a  degraded 
satellite  constellation. 

1.2  Research  Motivation 

This  thesis  provides  a  performance  analysis  of  the  IRIDIUM®  LEO  satellite 
system  with  a  degraded  satellite  constellation.  The  concept  of  LEO  satellite 
communications  (SATCOM)  is  relatively  new  and  provides  many  interesting  research 
opportunities.  This  is  exemplified  by  the  fact  that  several  commercial  organizations  are 
currently  developing  LEO  SATCOM  systems.  Two  such  systems,  IRIDIUM®  and 
GLOBALSTAR,  are  scheduled  to  be  operational  in  1998.  They  will  both  provide 
worldwide  voice,  data,  facsimile  and  paging  services.  The  IRIDIUM®  system  will  be  the 
first  commercial  system  to  use  inter-satellite  communication  links.  In  effect,  this  will 
form  a  network  in  the  sky  with  satellites  acting  as  switching  nodes.  Subscribers  will  have 
a  single  telephone  number  and  a  handset  similar  in  size  to  a  cellular  telephone.  These 
LEO  satellite  networks  are  intended  to  augment  the  existing  terrestrial  and  cellular 
networks. 

My  personal  interest  in  this  area  of  research  is  motivated  in  part  by  my  experience 
as  a  U.S.  Army  Signal  Officer.  I  have  spent  the  last  ten  years  working  with  a  variety  of 
military  communications  systems.  There  have  been  two  noticeable  trends  in  military 
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communications  over  the  past  decade.  The  first  is  the  movement  toward  mobile 
communications  systems.  This  is  exemplified  by  the  Army's  fielding  of  Mobile 
Subscriber  Equipment  (MSE)  in  the  late  1980s.  MSE  is  an  area  communications  system 
that  provides  voice,  data,  and  facsimile  service  to  tactical  military  users.  One  of  the  key 
features  of  MSE  is  a  user's  ability  to  keep  the  same  telephone  number  as  he  moves 
around  the  battlefield.  MSE  also  provides  wireless  communications,  similar  to  cellular 
telephone  service,  through  the  use  of  Radio  Access  Units  (RAUs).  The  second  trend  in 
military  communications  is  the  movement  toward  commercial  equipment  standards.  In 
the  past,  military  communications  systems  were  stand-alone  systems.  Today,  they  are 
designed  to  interface  with  both  commercial  systems  and  other  military  systems.  The 
military  use  of  commercial  technology  has  become  so  common  that  the  military  has 
adopted  an  acronym  for  it,  Commercial  Off  The  Shelf  (COTS)  equipment.  The 
commercial  LEO  satellite  technology  currently  under  development  appears  to  have  good 
potential  for  future  integration  into  military  communications  systems.  A  survivability 
analysis  of  one  of  these  systems  will  provide  insight  into  the  feasibility  of  integrating 
commercial  LEO  satellite  technology  into  military  communications  systems. 

13  Overview  of  Results 

This  research  began  as  a  follow  on  to  Douglas  Stenger's  work  in  the  area  of 
IRIDIUM®  survivability  analysis  [Ste96].  Stenger's  research  focused  on  the 
performance  of  different  routing  algorithms  in  a  faulting  IRIDIUM®  network.  Stenger’s 
work  examined  the  Dijkstra,  Extended  Bellman  Ford,  and  DARTING  routing  algorithms 
with  different  numbers  of  non-operational  satellites  and  varying  loading  levels.  Stenger 
concluded  that  the  IRIDIUM®  network  was  highly  survivable.  His  results  showed 


2 


acceptable  end-to-end  delays  for  all  routing  algorithms  with  as  many  as  45%  of  the 
satellites  removed  from  the  IRIDIUM®  constellation.  However,  Stenger’s  research  had 
three  significant  areas  that  could  be  improved.  First,  long  simulation  run  times  limited 
Stenger’s  research  to  two  transmitting  earth  stations  and  an  11%  traffic  load.  Second,  he 
did  not  use  an  algorithmic  approach  to  select  which  satellites  to  remove  from  the 
constellation.  Finally,  he  did  not  analyze  the  effect  that  removing  satellites  from  the 
constellation  has  on  a  user's  ability  to  connect  to  the  network.  This  research  focused  on 
improving  the  analysis  of  the  IRIDIUM®  system  in  all  three  of  these  areas. 

This  research  improved  upon  Stenger's  work  both  by  increasing  the  loading  level 
and  by  algorithmically  selecting  which  satellites  to  remove  from  the  constellation.  It 
analyzed  low,  medium,  and  high  traffic  loading  levels  of  50%,  83%  and  100% 
respectively.  The  algorithm  selected  the  most  loaded  satellites  to  remove  from  the 
constellation.  This  research  also  increased  the  number  of  transmitting  earth  stations  to 
seven.  Using  more  than  two  earth  stations  allowed  the  analysis  of  both  uniform  and  non- 
uniform  traffic  distributions.  With  a  low  loading  level  and  a  uniform  traffic  distribution 
the  system  had  end-to-end  delays  below  400-ms  and  packet  rejection  rates  below  1% 
with  up  to  seven  non-operational  satellites.  This  was  consistent  with  Stenger’s  previous 
work.  At  a  high  loading  level  with  a  uniform  traffic  distribution  the  network  experienced 
packet  rejection  rates  above  1%  with  only  three  non-operational  satellites.  A  medium 
loading  level  with  a  non-uniform  traffic  distribution  produced  packet  rejection  rates 
above  3%  with  a  full  satellite  constellation.  The  results  of  this  research  demonstrated  that 
the  loading  level,  the  traffic  distribution,  and  the  algorithmic  selection  of  satellites  had  a 
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significant  effect  on  the  IRIDIUM®  system’s  capability  to  perform  with  a  degraded 
satellite  constellation. 

This  research  also  improved  upon  Stenger's  work  by  analyzing  the  ability  to 
access  the  IRIDIUM®  network  with  a  degraded  satellite  constellation.  The  results 
demonstrated  that  a  typical  North  American  city  exceeded  both  the  benchmark  of  12.04- 
minutes  maximum  continuous  outage  time  and  the  benchmark  of  55.41 -minutes  of 
cumulative  outage  time  with  five  non-operational  satellites.  So  even  though  the 
IRIDIUM®  system  had  acceptable  delay  performance  with  a  low  loading  level  and  seven 
non-operational  satellites,  the  ability  to  access  the  network  with  these  failed  satellites  was 
not  acceptable.  The  combination  of  end-to-end  delay  analysis  and  network  access 
analysis  provided  a  more  complete  assessment  of  the  IRIDIUM®  system. 

1.4  Summary 

This  chapter  has  defined  the  goal  of  this  research  and  provided  a  brief  summary  of 
the  motivation  to  study  LEO  satellite  network  performance.  Chapter  2  presents  a  review 
of  the  current  literature  in  the  area  of  LEO  satellites  and  network  survivability.  This 
includes  previous  work  in  IRIDIUM®  network  survivability.  Chapter  3  explains  the 
methodology  used  to  analyze  the  performance  of  the  IRIDIUM®  system  and  discusses 
the  design  and  testing  of  the  simulation  model.  Chapter  4  provides  the  results  of  the 
simulation  runs  and  analyzes  these  results.  Chapter  5  contains  conclusions  from  the 
research  and  recommendations  for  additional  research  in  the  area  of  LEO  satellite 
networks. 
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CHAPTER  2 


LITERATURE  REVIEW 


2.1  Introduction 

This  goal  of  this  chapter  is  to  provide  the  theoretical  background  necessary  to 
model  and  analyze  the  performance  of  the  IRIDIUM®  system.  There  is  currently  a 
renewed  interest  in  the  development  of  a  LEO  satellite  system  that  provides  worldwide 
personal  communication  services  (PCS).  PCS  devices,  such  as  pagers  and  cellular 
telephones,  were  considered  luxury  items  as  recently  as  1990.  However,  over  the  past 
several  years  the  number  of  PCS  devices  in  use  has  increased  drastically.  In  July,  1993 
there  were  over  25  million  cellular  phones  worldwide,  and  recent  estimates  indicate  this 
number  will  increase  to  over  100  million  by  the  year  2000  [Ana95].  Technological 
advances  have  made  worldwide  mobile  communications  a  realistic  possibility.  Several 
commercial  consortiums  are  planning  LEO  satellite  networks  that  will  be  in  service 
before  the  year  2000  [Bru96].  These  networks  will  provide  a  range  of  worldwide 
services  including  voice,  data,  facsimile  and  paging.  This  chapter  presents  an  overview 
of  these  systems  focusing  primarily  on  the  IRIDIUM®  LEO  satellite  network. 

The  chapter  begins  with  a  brief  history  of  satellite  communications  in  Section  2.2. 
Section  2.3  introduces  three  categories  of  satellite  networks,  the  geostationary  earth  orbit 
(GEO),  medium  earth  orbit  (MEO)  and  LEO.  The  characteristics,  advantages,  and 
disadvantages  of  each  type  of  network  are  discussed.  In  Section  2.4,  the  design  of  a  LEO 
satellite  network  is  discussed  based  upon  number  of  satellites,  altitude  of  orbits,  and 
location  of  switching  nodes.  Section  2.5  compares  the  characteristics  of  GLOBALSTAR 
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and  IRIDIUM®,  two  commercial  LEO  networks  that  are  currently  under  development. 
In  Section  2.6,  the  establishment  of  inter-satellite  links  (ISLs)  is  discussed  with  respect  to 
antenna  pointing  angles  between  satellites.  The  IRIDIUM®  system  capacity  is  discussed 
in  Section  2.7.  In  Section  2.8,  the  process  of  call  establishment  and  setup  in  the 
IRIDIUM®  network  is  explained.  This  includes  a  discussion  of  both  the  format  of  an 
IRIDIUM®  phone  number  and  the  function  of  IRIDIUM®  gateways.  Section  2.9 
presents  an  overview  of  network  survivability  and  Section  2.10  discusses  previous  work 
in  the  area  of  IRIDIUM®  network  survivability  analysis. 

2.2  Brief  History  of  Satellite  Communications 

A  satellite  communication  system  is  basically  a  microwave  radio  system  with  a 
single  repeater.  Ground  stations  transmit  signals  to  the  satellite  via  the  uplink.  The 
satellite  transponder  serves  as  the  repeater,  and  retransmits  the  signals  over  the  downlink. 
The  satellite  downlink  is  broadcast  in  the  satellite  coverage  area.  The  first 
communication  satellite  was  placed  in  orbit  in  1958  [Saa94].  The  first  commercial  GEO 
satellite,  INTELSAT  I,  was  launched  in  1965.  It  used  50-MHz  of  bandwidth  and 
provided  240  voice  circuits  between  the  United  States  and  Europe.  INTELSAT  I  utilized 
non-linear,  hard  limited  transponders  and  only  two  ground  stations  could  access  the 
satellite  simultaneously.  INTELSAT  n  and  HI  used  travelling  wave  tubes  operating  in 
the  linear  region,  which  improved  multiple  access  to  the  satellite.  The  current  version, 
INTELSAT  VI,  was  launched  in  1989.  It  uses  33-GHz  of  bandwidth  and  simultaneously 
carries  120,000  voice  channels  and  3  television  channels  [Skl88].  The  first  generation  of 
GEO  satellite  mobile  communications  began  with  INMARSAT-A  in  1982  [Com93, 
Ana95].  The  ship-based  user  stations  had  a  40  W  transmitter  and  a  1.2-meter  dish 
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antenna  [Com93].  The  current  version,  INMARSAT-M,  became  operational  in  1993  and 
has  suitcase-sized  user  terminals  [Ana95].  Today,  satellite  communication  is  a  vital  part 
of  international  business  and  global  communications. 

2.3  Characteristics  of  GEO,  LEO  and  MEO  Satellite  Systems 

Existing  satellite  communication  systems  primarily  use  GEO  satellites  with  an 
altitude  of  approximately  35,800-km  [Com93,  Vat95].  GEO  satellite  systems  have  the 
advantage  of  allowing  full  earth  coverage,  below  70  degrees  latitude,  with  as  few  as  three 
satellites.  GEO  satellites  are  also  easy  to  track  since  they  appear  stationary  with  respect 
to  a  point  on  earth.  However,  GEO  satellite  systems  have  the  disadvantages  of  high 
propagation  delay  and  high  propagation  loss.  The  one  way  propagation  delay  of  a  GEO 
satellite  system  is  approximately  120-ms.  The  propagation  loss  for  a  radio  frequency 
signal  is  directly  proportional  to  the  square  of  the  path  distance.  This  is  described  in 
Equation  1  where  X  equals  wavelength  and  d  equals  path  distance: 


It  is  necessary  to  use  either  a  high  power  transmitter  or  a  large  antenna  to  compensate  for 
the  propagation  loss  associated  with  transmitting  over  a  distance  of  35,800-km.  This 
increases  the  size  and  weight  of  ground  satellite  stations  and  makes  hand-held  user 
terminals  impractical.  Another  disadvantage  of  GEO  satellite  systems  is  that  they  orbit 
above  the  Van  Allen  belt.  As  a  result,  the  satellites  must  be  hardened  to  protect  the 
electronics.  This  increases  the  weight  and  fabrication  cost  of  the  satellite. 

LEO  satellites  orbit  at  an  altitude  between  500-km  and  1 ,500-km  and  move  with 
respect  to  a  point  on  earth.  The  primary  advantages  of  LEO  satellites  are  a  lower 
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propagation  delay,  lower  required  transmit  power,  and  polar  coverage.  The  one-way 
propagation  delay  of  a  LEO  satellite  system  is  between  1.7-ms  and  5-ms.  The 
propagation  loss  that  results  from  transmitting  500-km  to  1,500-km  is  low  enough  to 
allow  hand-held  battery  powered  user  terminals.  LEO  satellite  networks  use  numerous 
satellites  in  near-polar  orbits  to  provide  worldwide  coverage  including  the  polar  regions. 
Also,  since  the  altitude  of  LEO  satellites  is  below  the  Van  Allen  belt  they  do  not  have  to 
be  hardened.  This  means  that  the  satellites  are  lighter,  cheaper  to  fabricate,  and  easier  to 
deploy.  The  most  significant  disadvantages  of  LEO  satellites  are  the  large  number  of 
satellites  required  for  worldwide  coverage,  and  the  difficult  task  of  tracking  satellites  that 
move  with  respect  to  ground  stations. 

MEO  satellites  orbit  at  an  altitude  between  5,000-km  and  20,000-km  and  offer  a 
compromise  between  GEO  and  LEO  satellites.  A  MEO  satellite  system  has  a  lower 
propagation  delay  than  a  GEO  satellite  system,  and  has  both  fewer  satellites  and  easier 
tracking  than  a  LEO  satellite  system.  The  one  way  propagation  delay  of  a  MEO  satellite 
system  is  between  16.7-ms  and  66.7-ms.  This  is  low  enough  that  a  signal  between  two 
users  can  traverse  two  complete  MEO  satellite  links  and  remain  within  CCITT 
Recommendations  G.114  for  end-to-end  delay  [Vat95].  MEO  satellites  provide 
worldwide  coverage  with  as  few  as  10  satellites.  MEO  satellites  are  visible  to  an  earth 
station  for  approximately  two  hours,  while  LEO  satellites  are  visible  for  about  ten 
minutes.  This  simplifies  the  tasks  of  tracking  the  satellites  and  handing  off  calls  between 
satellites.  The  main  disadvantage  of  MEO  satellites  is  that  the  propagation  loss  is  too 
large  to  make  hand-held  user  terminals  practical.  Odyssey  is  a  proposed  commercial 
MEO  system  that  will  have  four  satellites  in  each  of  three  orbital  planes  for  a  total  of  12 
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satellites.  The  orbits  will  have  an  altitude  of  10,600-km  and  an  inclination  of  55  degrees 
relative  to  the  equator.  Although  MEO  satellites  are  not  well  suited  for  PCS,  the  long 
overhead  periods  could  prove  useful  in  maritime  applications  where  there  is  less  of  a 
requirement  for  small  terminals. 

2.4  Design  of  a  LEO  Satellite  Network 

There  are  different  approaches  to  designing  a  LEO  satellite  network  that  vary 
based  upon  the  type  of  service  provided,  the  satellite  constellation,  and  the  network 
connectivity.  The  type  of  service  provided  by  a  LEO  satellite  network  is  classified  by  the 
bandwidth  and  delay  requirements.  Big  LEO  systems  will  provide  a  higher  bandwidth 
and  lower  delay  service  that  is  suitable  for  voice  applications.  Little  LEO  systems  will 
provide  a  lower  bandwidth  and  higher  delay  service  that  can  support  facsimile,  electronic 
mail,  and  paging  services.  Most  current  commercial  designs  are  Big  LEO  systems  that 
plan  to  offer  voice,  facsimile,  and  paging  services. 

The  design  of  a  LEO  satellite  constellation  involves  selecting  the  number  of 
satellites,  the  altitude  of  the  orbits,  the  minimum  elevation  angle,  the  number  of  orbits, 
and  the  number  of  spot  beams  in  a  satellite  footprint.  The  number  of  satellites  is  selected 
to  provide  full  earth  coverage  based  on  each  satellite's  coverage  area.  The  coverage  area 
of  a  single  satellite,  depicted  in  Figure  1,  is  given  by  Equation  2  where  Re  is  the  radius  of 
the  earth  and  9  is  the  earth  central  angle  [Gag84]. 

A  =  2nR)  (l-cos0)  (2) 

The  earth  central  angle  9  is  calculated  using  Equation  3  where  Re  is  the  radius  of  the 
earth,  E  is  the  minimum  elevation  angle,  and  h  is  the  satellite  altitude  [Gag84]. 
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The  altitude  of  the  satellite  and  the  minimum  elevation  angle  determine  the  size  of  the 
coverage  area  with  a  higher  altitude  and  lower  elevation  angle  resulting  in  a  larger 
coverage  area.  In  general,  the  number  of  satellites  required  for  global  coverage  is 
inversely  proportional  to  the  satellite  altitude.  The  propagation  distance  to  the  satellite  is 
also  a  function  of  the  satellite  altitude.  The  minimum  propagation  distance  occurs  when 
the  satellite  is  directly  overhead  and  is  equal  to  the  satellite  altitude.  The  maximum 
propagation  distance,  depicted  as  din  Figure  1,  is  calculated  using  Equation  4. 


Figure  1:  Satellite  Coverage  Area 

The  number  of  satellites,  S,  are  arranged  in  m  orbits  with  n  satellites  equally  spaced  in 
each  orbit  according  to  the  equation  S  —  m  x  n.  The  m  orbits  are  spaced  approximately 
180/m  degrees  apart.  A  satellite  with  higher  altitude  has  a  larger  coverage  area,  but  its 
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transmitted  power  is  effectively  spread  across  the  area  of  coverage.  Therefore,  a  higher 
altitude  satellite  requires  a  higher  transmitted  power  in  order  for  a  user  to  have  the  same 
received  signal  power.  The  underlying  design  trade-off  is  between  the  number  of 
satellites  required  and  the  transmitter  power  required  on  the  satellite.  An  approach  to 
reducing  the  power  required  on  the  satellite  is  to  use  multiple  spot  beam  antennas.  Each 
spot  beam  focuses  its  power  in  a  small  portion  of  the  footprint  and  uses  a  lower 
transmitter  power.  Another  aspect  of  the  satellite  constellation  that  is  dependent  on  the 
satellite  altitude  is  the  velocity  of  the  satellite  relative  to  the  earth.  The  velocity  of  a  LEO 
satellite  relative  to  the  earth  is  given  by  Equation  5  where  0)  is  the  earth  angular  rotation 
speed,  Rg  is  the  GEO  satellite  orbit  radius,  and  Ri  is  the  LEO  satellite  orbit  radius 
[Gan93]. 
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The  angular  rotation  of  the  earth  is  calculated  as  0.2618-radians/hour  using  Equation  6. 


2  n  radians  _ 

(O  = - -  0.261 8  radians  /  hour  (6) 

24  hours 

Lower  satellites  have  a  higher  velocity  relative  to  earth  and  are  visible  for  a  shorter 
amount  of  time.  This  contributes  to  the  difficulty  in  tracking  the  satellites. 

There  are  currently  two  design  approaches  for  connectivity  in  a  LEO  satellite 
network.  These  approaches  depend  upon  whether  the  satellites  serve  as  repeaters,  or  if 
they  have  onboard  switching  equipment.  A  "bent  pipe"  architecture  uses  satellites  that 
serve  as  repeaters.  A  mobile  user's  transmitted  signal  is  received  and  retransmitted  by  the 
satellite  to  a  gateway  in  the  same  satellite  footprint.  The  switch  used  to  process  the  call  is 


11 


located  at  the  gateway.  Locating  the  switches  at  the  gateways  simplifies  the  satellite 
design  and  allows  for  future  upgrades  to  the  switching  equipment.  This  type  of  system 
requires  a  gateway  in  each  satellite  footprint  in  order  to  interface  mobile  users.  Satellites 
with  onboard  switching  equipment  are  able  to  use  inter-satellite  links  (ISLs)  to  route 
calls.  A  mobile  user's  transmitted  signal  is  routed  through  several  satellites  and 
downlinked  to  either  a  regional  gateway  or  another  mobile  user.  This  creates  a  network 
in  the  sky  and  allows  the  use  of  large  regional  gateways  instead  of  gateways  in  each 
satellite  footprint.  However,  the  switching  equipment  increases  the  weight  of  the 
satellites.  The  heavier  satellites  are  more  expensive  to  launch  and  have  a  shorter  life 
span.  Placing  the  switching  equipment  on  the  satellite  requires  very  precise  orbits  for 
tracking  of  ISLs.  It  also  means  that  new  satellites  must  be  launched  to  upgrade  switching 
equipment. 

2.5  Overview  of  Planned  LEO  Satellite  Networks 

Two  proposed  commercial  LEO  systems  that  use  different  constellation  and 
connectivity  designs  are  GLOBALSTAR  and  IRIDIUM®.  The  characteristics  of  these 
networks  are  summarized  in  Table  1.  The  GLOBALSTAR  network  is  being  developed 
by  a  group  of  companies  that  includes  Loral,  QUALCOMM,  SS/L,  AirTouch  and 
numerous  others  [Com93].  The  network  will  provide  voice,  data,  paging  and  facsimile 
services.  The  satellite  constellation  has  48  satellites  in  8  orbits  at  an  altitude  of  1,400-km. 
The  network  topology  uses  "bent  pipe"  transmission  links  and  switching  at  the  gateways. 
The  technology  needed  to  manufacture  satellites  that  perform  as  relays  is  widely  used  in 
GEO  satellites.  As  such,  the  GLOBALSTAR  LEO  network  is  being  developed  around 
existing  technology  and  is  a  relatively  conservative  design. 
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Table  1 :  Comparison  ofGLOBALSTAR  and  IRIDIUM® 


IRIDIUM® 

Altitude  (Km) 

1400 

780 

No.  of  Satellites 

48 

66 

No.  of  Orbits 

8 

6 

Inclination  of  Orbits  (deal 

52 

86 

No.  of  SDOt  Beams 

16 

48 

Switchina 

Satellite 

Link  TvDe 

Bent  PiDe 

ISL 

Weiaht  (lbs.) 

510 

1516 

Life  Span  (vears) 

7.5 

5  to  7 

Modulation 

CDMA 

TDMA/FDMA 

In  the  GLOBALSTAR  network,  user  uplinks  will  utilize  the  frequency  range  of  1.610  to 
1 .625-GHz  and  user  downlinks  will  utilize  the  frequency  range  of  2.4835  to  2.500-GHz 
[Com93].  A  GLOBALSTAR  satellite  will  have  2,800  full  duplex  circuits  [Com93].  The 
fact  that  GLOBALSTAR  uses  Code  Division  Multiple  Access  (CDMA)  modulation  is 
technically  significant  because  the  consortium  plans  to  have  one  hand-held  device  for 
cellular  and  satellite  communications.  Many  existing  cellular  telephone  networks  use 
CDMA  technology,  and  it  is  advantageous  to  use  the  same  modulation  for  both  the 
cellular  and  satellite  portions  of  the  hand-held  device.  The  first  GLOBALSTAR 
satellites  are  scheduled  to  be  launched  in  early  1998. 

The  IRIDIUM®  system  is  being  developed  by  an  international  consortium  of 
telecommunications  companies  that  includes  Motorola,  Raytheon,  Siemens,  Telesat  and 
Bechtel  [Bru96,  Com93].  Like  GLOBALSTAR,  it  will  offer  voice,  data,  paging  and 
facsimile  services.  The  IRIDIUM®  satellite  constellation  consists  of  six  orbital  planes 
with  eleven  satellites  in  each  plane  for  a  total  of  66  LEO  satellites.  The  satellites  are 
arranged  using  the  Adams/Rider  circular  polar  constellation  [Kel96,  Ada87].  The 
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satellites  are  in  a  circular  orbit  at  an  altitude  of  approximately  780-km  and  at  an 
inclination  of  86.4  degrees.  Orbital  planes  one  and  six  are  counter-rotating  and  are 
separated  by  approximately  22  degrees.  The  remaining  orbital  planes  are  co-rotating  and 
are  separated  by  approximately  31.6  degrees  [Hub97].  The  most  significant  aspect  of 
IRIDIUM®  is  that  it  is  currently  the  only  commercial  network  that  plans  to  use  both  ISLs 
and  switching  equipment  on  the  satellites.  The  IRIDIUM®  uplinks  and  downlinks  will 
use  a  combination  of  Time  Division  Multiple  Access  (TDMA)  and  Frequency  Division 
Multiple  Access  (FDMA)  for  multiple  access  to  the  satellite.  The  TDMA  frame  is  90-ms 
long  and  accommodates  four  50-kbps  user  accesses  per  frame  [Hub97].  The  TDMA 
scheme  allows  the  same  frequencies  to  be  used  on  both  the  uplink  and  downlink  without 
interference.  In  the  IRIDIUM®  network,  user  uplinks  and  downlinks  will  both  utilize  the 
frequency  range  of  1.616  to  1.6265-GHz.  An  IRIDIUM®  satellite  will  have  3840  full 
duplex  circuits.  The  IRIDIUM®  network  is  an  aggressive  design  using  untested 
technology.  However,  the  aggressive  design  has  potential  benefits  in  area  of  coverage. 
The  IRIDIUM®  network  allows  two  mobile  subscribers  to  communicate  without  the  call 
going  through  a  gateway.  In  addition,  the  network  offers  potential  advantages  for 
communication  over  water  where  the  proper  placement  of  gateways  is  difficult.  The 
IRIDIUM®  network  is  scheduled  to  be  operational  in  late  1998. 

2.6  IRIDIUM®  ISL  Connectivity 

The  IRIDIUM®  network  will  have  up  to  four  ISLs  for  each  satellite  operating  at  a 
data  rate  of  25-Mbps  in  the  22.55  to  23.55-GHz  frequency  range  [Com93,  Hub97].  The 
length  of  these  links  is  approximately  4,000-km.  Two  of  these  links  will  be  intra-orbital 
links  to  the  forward  and  aft  adjacent  satellites  in  the  same  orbital  plane.  There  will  also 
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be  up  to  two  inter-orbital  links,  one  each  to  the  two  adjacent  orbital  planes.  The 
horizontal  pointing  angle  between  two  satellites  in  adjacent  orbital  planes,  using  a 
reference  of  zero  degrees  parallel  to  the  equator,  varies  between  approximately  ±65 
degrees  over  one  orbital  period  [Kel96,  Wer95].  This  angle  varies  most  slowly  over  the 
equator  where  satellites  in  adjacent  orbits  are  the  most  separated,  and  it  varies  most 
rapidly  over  the  poles  where  the  orbits  cross.  The  variation  in  horizontal  azimuth 
between  satellites  makes  antenna  steering  necessary  to  maintain  inter-orbital  links.  Even 
with  antenna  steering,  it  would  be  very  difficult  to  maintain  inter-orbital  links  at  higher 
latitudes  where  the  azimuth  varies  rapidly.  An  approach  to  maintaining  inter-orbital  links 
is  to  select  a  nominal  horizontal  azimuth  close  to  that  between  satellites  over  the  equator. 
Then  the  antenna  is  designed  to  have  a  steering  range  that  allows  inter-orbital  links  at 
lower  latitudes  where  the  horizontal  azimuth  changes  more  slowly.  A  nominal  horizontal 
azimuth  of  ±  45  to  50  degrees  with  an  antenna  steering  range  of  30  to  45  degrees  is 
sufficient  to  maintain  inter-orbital  links  between  latitudes  of  50  to  60  degrees  north  and 
south  [Kel96,  Wer95].  Although  the  actual  characteristics  of  the  ISL  antennas  on 
IRIDIUM®  satellites  are  not  known,  this  approach  is  reasonable  since  it  allows  inter¬ 
orbital  ISLs  over  the  most  populated  regions  of  the  earth. 

2.7  IRIDIUM®  System  Capacity 

The  IRIDIUM®  system  uses  a  combination  of  TDMA  and  FDMA.  The  TDMA 
frame  is  90-ms  long  and  it  contains  four  full  duplex  user  channels  at  a  burst  data  rate  of 
50-kbps  [Com93,  Hub97,  Gea96].  The  IRIDIUM®  TDMA  frame  structure  is  shown  in 
Figure  2.  The  four  full  duplex  channels  consist  of  four  uplink  time  slots  and  four 
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downlink  time  slots.  The  IRIDIUM®  system  will  support  full  duplex  voice  channels  at 
4,800-bps  and  half  duplex  data  channels  at  2,400-bps  [Com93]. 


TDMA  Frame  Structure 

Guard  Time 


Figure  2:  IRIDIUM®  TDMA  Frame  Structure 
IRIDIUM®  uses  frequencies  in  the  L-band  of  1.616  to  1.6265-GHz  for  the 
user's  uplink  and  downlink  with  the  satellites  [Com93,  Hub97].  This  gives  the  system 
10.5-MHz  of  bandwidth.  The  IRIDIUM®  FDMA  scheme  divides  the  available 
bandwidth  into  240  channels  of  41 .67 -kHz  for  a  total  of  10-MHz  [Gea96].  This  leaves 
500-kHz  of  bandwidth  for  guard  bands,  which  amounts  to  approximately  2-kHz  of  guard 
band  between  channels.  The  IRIDIUM®  FDMA  scheme  is  shown  in  Figure  3. 


Figure  3:  IRIDIUM®  FDMA  Scheme 

The  IRIDIUM®  network  utilizes  multiple  spot  beams  on  each  satellite  that  divide 
the  satellite  footprint  into  smaller  cells.  Each  IRIDIUM®  satellite  has  three  phased  array 
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antennas  with  16  spot  beams  for  a  total  of  48  spot  beams  on  the  satellite  [Com93, 
Hub97].  A  spot  beam,  like  a  cell  in  a  typical  cellular  network,  is  assigned  a  fraction  of 
the  available  frequency  channels.  Frequency  channels  can  be  reused  throughout  the 
network  by  assigning  them  to  cells  that  are  far  enough  apart  to  minimize  co-channel 
interference.  The  IRIDIUM®  network  uses  a  frequency  reuse  factor  of  12,  which  means 
there  are  12  cells  in  each  cluster  [Hub97],  As  shown  in  Equation  7,  this  equates  to  20 
frequency  channels  per  cell. 


240  channels 
12  cells 

The  frequency  reuse  factor  is  described 
integers. 


=  20  channels  per  cell  (7) 

by  Equation  8  where  I  and  J  are  non-negative 


N  =  I2  + 1  -J  +  J2  (8) 

Cells  that  use  the  same  frequency  channels  are  found  by  starting  in  the  center  of  a  cell, 
moving  I  cells  across  cell  sides,  turning  60  degrees,  and  moving  J  cells.  This  is 
illustrated  in  Figure  4  where  cells  with  the  same  letter  use  the  same  frequency  channels. 

The  capacity  of  the  IRIDIUM®  network  can  be  calculated  by  multiplying  the 
number  of  possible  users  per  cell  by  the  number  of  active  cells  in  the  network.  Each  cell 
has  four  TDMA  channels  on  20  frequencies  for  a  total  of  80  possible  users.  The 
IRIDIUM®  network  has  48  cells  on  each  of  the  66  satellites  for  a  total  of  3,168  cells. 
Since  some  of  the  spot  beams  will  overlap,  especially  near  the  poles,  only  2,150  of  the 
possible  3,168  cells  will  be  active  at  once  [Hub97].  The  remaining  spot  beams  will  be 
turned  off  to  conserve  power.  The  network  has  80  users  in  2,150  active  cells  for  a  total 
network  capacity  of  172,000  simultaneous  users. 
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Figure  4:  IRIDIUM®  Frequency  Reuse  Scheme 
This  maximum  network  capacity  implies  that  the  users  are  distributed  across  all  the 
active  beams.  The  calculation  does  not  take  into  account  the  fact  that  many  of  the 
satellites  will  be  over  the  ocean  or  other  low  populated  areas.  Each  satellite  has  80  users 
in  48  cells  for  a  maximum  of  3,840  simultaneous  users  per  satellite.  The  size  of  an 
IRIDIUM®  satellite  footprint  is  calculated  as  15,299,900-km2  using  Equations  2  and  3. 
Each  IRIDIUM®  satellite  is  therefore  capable  of  supporting  an  average  of  one 
simultaneous  user  per  3,984-km2  of  coverage  area. 

2.8  IRIDIUM®  Call  Processing 

The  IRIDIUM®  system  will  allow  users  to  roam  worldwide  and  still  utilize  a 
single  subscriber  number.  To  accomplish  this,  each  user  will  have  a  home  gateway  that 
normally  provides  his  service.  The  gateways  in  this  system  will  be  regional  and  will 
support  large  geographical  areas.  For  example,  a  single  gateway  will  service  North 
America.  The  gateways  serve  as  the  interface  to  the  Public  Switched  Telephone  Network 
(PSTN).  They  also  perform  the  functions  of  call  setup,  call  location  and  billing.  The 
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gateway  must  maintain  a  database  of  subscriber  profiles  as  well  as  subscriber  locations. 
This  register  is  called  the  Home  Location  Register  (HLR). 

An  IRIDIUM®  subscriber  will  be  uniquely  identified  by  three  numbers,  the 
Mobile  Subscriber  Integrated  Services  Digital  Network  Number  (MSISDN),  the 
Temporary  Mobile  Subscriber  Identification  (TMSI),  and  the  Iridium  Mobile  Subscriber 
Identity  (IMSI)  [Hub97].  The  MSISDN  is  the  telephone  number  of  an  IRIDIUM® 
subscriber.  The  MSISDN  is  five  digits  long,  and  makes  up  part  of  the  twelve-digit 
number  dialed  to  reach  a  subscriber.  The  first  field  of  the  twelve-digit  number  is  the 
four-digit  country  code.  This  is  similar  to  the  country  codes  used  now  with  the  PSTN. 
The  IRIDIUM®  network  will  have  its  own  country  codes  and  is  currently  assigned  the 
codes  8816  and  8817  [Hub97].  The  second  field  of  the  number  is  a  three  digit 
geographical  code.  This  code  will  be  used  to  identify  a  user's  home  country  in  regions 
where  one  gateway  services  more  than  one  country.  The  third  and  final  field  of  the 
number  is  the  MSISDN.  The  TMSI  is  a  temporary  number  that  is  transmitted  over  the 
network  during  call  setup.  This  number  is  changed  periodically  to  protect  subscriber 
confidentiality  [Hub97].  The  IMSI  is  a  permanent  number  stored  on  a  credit  card  sized 
module  that  the  subscriber  inserts  into  the  mobile  phone  unit.  This  number  contains 
information  that  allows  a  gateway  to  uniquely  identify  a  user  and  determine  his  home 
gateway. 

The  IRIDIUM®  network  must  track  a  user's  location  as  he  roams  in  order  to  set 
up  calls.  When  a  subscriber  turns  on  his  mobile  phone  unit,  it  transmits  a  "ready  to 
receive"  signal  to  the  nearest  gateway.  The  signal  is  uplinked  from  the  user  to  the 
satellite  directly  overhead.  If  the  user  is  not  in  the  same  satellite  footprint  as  the  gateway, 
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the  signal  traverses  ISLs  until  it  reaches  the  satellite  that  is  above  the  gateway.  The 
signal  is  then  downlinked  to  the  gateway.  If  the  user  is  not  in  his  home  gateway  region, 
the  gateway  that  receives  the  "ready  to  receive"  signal  will  recognize  that  the  user  is  a 
visiting  subscriber.  The  gateway  determines  the  subscriber's  location  and  enters  the 
information  in  the  Visited  Location  Register  (VLR).  The  visited  gateway  also  sends 
information  via  ISLs  to  the  subscriber's  home  gateway  and  requests  both  a  subscriber 
profile  and  permission  to  set  up  calls  for  the  subscriber.  The  home  gateway  sends 
clearance  to  the  visited  gateway  and  updates  the  user's  location  in  the  HLR. 

The  gateways  perform  call  setup  in  the  IRIDIUM®  network.  When  a  phone  call 
is  placed  to  an  IRIDIUM®  user,  it  is  routed  to  the  user's  home  gateway.  This  call  can  be 
placed  from  the  PSTN  or  from  another  IRIDIUM®  user.  The  user's  home  gateway 
determines  the  user  location  by  looking  up  the  subscriber  in  the  HLR.  The  gateway  then 
uplinks  a  ring  signal  that  travels  via  ISL  to  the  satellite  directly  above  the  user.  The 
signal  is  downlinked  to  the  mobile  unit  and  it  rings.  When  the  user  goes  off  hook,  the 
mobile  unit  uplinks  an  off  hook  signal  that  travels  via  ISL  to  the  gateway.  The  gateway 
then  routes  the  voice  packets  over  the  IRIDIUM®  network  to  the  subscriber.  Note  that 
the  voice  packets  do  not  have  to  be  routed  through  the  gateway.  If  the  call  is  from  a 
mobile  user  to  a  mobile  user,  the  actual  voice  packets  can  travel  completely  over  the 
IRIDIUM®  ISLs.  The  call  setup  information  goes  through  the  gateway,  but  the  gateway 
drops  out  after  call  setup.  The  scenario  is  slightly  different  if  the  user  is  in  a  visited 
gateway  region.  In  this  case,  the  home  gateway  will  send  a  signal  to  the  visited  gateway 
to  ring  the  subscriber.  The  visited  gateway  determines  the  user  location  by  looking  in  the 
VLR  and  uplinks  a  ring  signal  that  goes  to  the  satellite  over  the  user.  When  the  user  goes 
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off  hook,  the  off  hook  signal  is  sent  to  the  visited  gateway,  and  then  forwarded  to  the 
home  gateway.  Finally,  the  home  gateway  routes  the  voice  packets  via  the  IRIDIUM® 
ISLs  to  the  satellite  directly  above  the  user.  The  methods  used  for  call  setup  in 
IRIDIUM®  are  very  similar  to  those  used  by  the  Advanced  Mobile  Phone  System 
(AMPS)  cellular  telephone  system  [Hub97]. 

2.9  Network  Survivability 

The  survivability  of  a  telecommunications  network  is  a  measure  of  the  network's 
ability  to  route  calls  or  deliver  messages,  between  any  two  nodes,  with  links  or  nodes 
removed  from  the  network.  One  method  of  determining  the  survivability  of  a  network  is 
to  represent  it  as  a  graph  and  determine  the  connectivity  of  the  graph.  Graph  connectivity 
is  a  measure  of  either  link  or  node  redundancy  in  the  network.  Link  connectivity  between 
two  nodes  A  and  B  is  defined  as  the  number  of  links  that  must  be  removed  to  disconnect 
A  and  B.  Likewise,  node  connectivity  is  the  number  of  nodes  that  must  be  removed  from 
the  network  to  disconnect  A  and  B.  A  network  in  which  k  nodes  or  links  must  be 
removed  in  order  to  disconnect  one  or  more  nodes  is  termed  k-connected.  Menger's 
Theorem  states  that  the  maximum  number  of  link  (node)  disjoint  paths  between  nodes  A 
and  B  in  a  connected  graph  is  equal  to  the  minimum  number  of  links  (nodes)  that  must 
removed  to  disconnect  A  and  B  [Dol93].  Applying  Menger's  theorem  to  a 
communications  network  means  that  the  connectivity  of  a  network  is  equal  to  the  number 
of  link  or  node  disjoint  paths.  Requiring  a  communications  network  to  be  at  least  k- 
connected  is  a  deterministic  approach  to  using  network  connectivity  as  a  measure  of 
network  survivability.  This  makes  it  possible  to  specify  how  many  links  (nodes)  can  fail 
without  preventing  the  network  from  performing  its  function.  It  is  also  possible  to  use  a 


21 


stochastic  approach  by  assigning  a  probability  of  failure  to  individual  links  or  nodes. 
This  makes  it  possible  to  determine  the  probability  that  two  specific  nodes  will  become 
disconnected  [New91,  Rai91]. 

The  ability  to  measure  the  survivability  of  a  network  by  determining  its 
connectivity  leads  to  the  concept  of  determining  critical  nodes  or  links.  Each  node  and 
link  in  a  network  can  be  assigned  a  weight  based  upon  how  important  it  is  to  network 
connectivity.  This  is  illustrated  with  the  simple  network  in  Figure  5.  It  is  easy  to  see  that 
nodes  A  and  G  have  a  node  connectivity  of  one  since  all  paths  between  these  nodes  go 
through  node  D.  In  this  case,  node  D  is  a  critical  node  in  the  network  since  its  removal 
will  disconnect  nodes  A  and  G. 


Figure  5:  Simple  One  Connected  Network 

Once  you  are  able  to  determine  critical  nodes  or  links,  it  is  possible  to  improve  the 
network  survivability  by  balancing  the  importance  of  nodes  or  links  in  the  network.  This 
is  accomplished  by  changing  the  physical  topology  of  the  network  with  the  addition  of 
nodes  or  links.  The  relative  importance  of  the  nodes  for  the  network  in  Figure  5  can  be 
balanced  by  adding  a  single  link  between  nodes  C  and  F.  As  shown  in  Figure  6,  adding 
this  link  results  in  a  two  connected  network.  In  order  to  disconnect  nodes  A  and  G,  a 
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minimum  of  two  nodes  must  be  removed.  The  combinations  of  two  nodes  that  will 


disconnect  nodes  A  and  G  are  B-C,  C-D,  D-F,  and  E-F.  Note  that  the  addition  of  a  link 
between  nodes  B  and  E  in  Figure  5  will  also  produce  a  two-connected  network.  This 
simple  example  also  illustrates  the  fact  that  improving  the  survivability  of  the  network  by 
adding  links  increases  the  cost  of  the  network.  It  is  not  a  trivial  task  to  maximize  the 
survivability  and  simultaneously  minimize  the  cost  of  a  large  communications  network. 
There  are  several  approaches  to  solving  this  type  of  problem  using  both  deterministic  and 
stochastic  computer  algorithms  [New91,  Rai91].  The  result  of  each  of  these  algorithms  is 
a  balanced  network  in  which  it  is  difficult  to  determine  critical  nodes  based  upon  the 
physical  topology  of  the  network. 


Figure  6:  Simple  Two  Connected  Network 
The  determination  of  critical  nodes  in  a  balanced  network,  as  described  above, 
can  be  accomplished  if  additional  information  about  the  network  is  available.  One  means 
of  accomplishing  this  is  to  analyze  the  traffic  flow  in  the  network.  The  nodes  of  a 
network  may  appear  equally  important  based  upon  the  physical  topology  of  the  network. 
However,  some  nodes  may  be  more  important  because  they  have  a  higher  traffic  load 
than  other  nodes.  The  traffic  load  of  different  nodes  in  the  network  depends  upon  both 
the  routing  algorithm  and  the  distribution  of  traffic  between  transmitting  and  receiving 
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nodes.  Given  this  information,  it  is  possible  to  determine  which  nodes  will  be  the  most 
heavily  loaded.  In  a  well-connected  network,  the  failure  of  a  heavily  loaded  node  may 
not  disconnect  any  pair  of  nodes.  However,  the  traffic  that  was  flowing  through  the 
failed  node  must  now  be  routed  through  other  nodes.  Most  likely  this  will  result  in 
increased  queuing  delay  in  the  network.  It  is  important  to  note  that  the  type  of  routing 
algorithm  used  will  have  a  significant  effect  on  the  ability  to  determine  critical  nodes  in 
this  manner.  A  simple  routing  algorithm,  such  as  the  Dijkstra  shortest  path  routing 
algorithm,  makes  no  attempt  to  balance  the  load  across  the  network.  This  type  of 
algorithm  is  likely  to  produce  some  nodes  that  are  much  more  loaded  than  other  nodes. 
Likewise,  a  routing  algorithm  that  attempts  to  balance  the  network  load,  such  as  the 
extended  Bellman-Ford  routing  algorithm,  is  less  likely  to  produce  a  large  variance  in  the 
loading  of  nodes.  The  distribution  of  traffic  between  nodes  will  have  a  similar  effect.  A 
uniform  distribution  of  traffic  between  will  be  less  likely  than  a  non-uniform  distribution 
to  create  hot  spots  of  highly  loaded  nodes.  It  is  clear  that  an  understanding  of  both  the 
routing  algorithm  used  and  the  traffic  distribution  is  necessary  to  determine  critical  nodes 
in  a  balanced  network. 

2.10  IRIDIUM®  Network  Survivability 

There  is  currently  a  lack  of  published  research  in  the  area  of  LEO  satellite  system 
network  survivability.  The  only  research  currently  published  in  open  literature,  in  the 
area  of  IRIDIUM®  network  survivability,  was  performed  by  Douglas  Stenger  in  1996 
[Ste96].  The  research  focused  on  the  performance  of  IRIDIUM®,  using  three  different 
routing  algorithms,  in  a  faulting  environment.  Stenger  examined  the  performance  of  the 
Dijkstra,  Extended  Bellman-Ford,  and  Darting  routing  algorithms.  He  used  IRIDIUM® 
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constellations  with  66,  54,  42,  and  30  satellites.  Stenger  concluded  that  the  IRIDIUM® 
network  performed  with  end-to-end  delays  less  than  400-ms  in  all  cases.  However,  long 
simulation  times  limited  his  research  to  two  transmitting  earth  stations  and  a  maximum 
loading  level  of  1 1%.  While  Stenger’s  results  clearly  show  that  the  IRIDIUM®  network 
is  robust,  the  limited  number  of  earth  stations  and  low  loading  levels  do  not  provide  an 
assessment  of  how  the  network  will  perform  under  a  more  realistic  load.  In  addition, 
Stenger  did  not  analyze  the  effect  that  removing  satellites  from  the  constellation  had  on  a 
user's  ability  to  access  the  network.  The  removal  of  satellites  from  the  constellation  will 
cause  outage  times  when  users  are  unable  to  access  the  system.  As  the  number  of 
satellites  removed  increases,  a  user's  ability  to  access  the  network  decreases.  At  some 
point,  the  inability  to  access  the  network  will  become  more  important  to  the  user  than  the 
delay  performance.  The  lack  of  research  on  the  survivability  of  LEO  satellite  mobile 
communication  systems  like  IRIDIUM®  provides  the  motivation  for  this  research. 

2.11  Summary 

This  chapter  has  presented  an  overview  of  the  current  literature  in  the  areas  of 
LEO  satellite  communications,  the  IRIDIUM®  system,  and  network  survivability.  It 
began  with  an  overview  of  satellite  communications  and  a  comparison  of  GEO,  MEO  and 
LEO  satellite  networks.  This  comparison  revealed  that  LEO  satellites  have 
characteristics  that  are  well  suited  to  PCS  applications.  Next,  the  design  of  a  LEO 
satellite  network  was  examined  as  a  tradeoff  between  the  number  of  satellites  required  for 
worldwide  coverage  and  the  transmit  power  required  in  mobile  units.  GLOBALSTAR 
and  IRIDIUM®,  two  different  commercial  LEO  satellite  networks,  were  compared. 
GLOBALSTAR  utilizes  a  "bent  pipe"  approach  while  IRIDIUM®  has  both  ISLs  and 
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switching  capability  onboard  the  satellites.  The  establishment  of  ISLs  and  the  system 
capacity  of  IRIDIUM®  were  explained.  The  call  setup  procedure  for  IRIDIUM®  was 
explained  with  respect  to  the  functions  of  a  gateway.  An  overview  of  network 
survivability  was  presented  as  an  introduction  to  a  discussion  of  IRIDIUM®  network 
survivability.  The  literature  presents  a  large  amount  of  information  on  LEO  satellite 
networks,  as  well  as  on  network  survivability.  Graph  theory  in  static  communication 
networks  is  well  established.  However,  there  is  a  lack  of  research  in  the  area  of  mobile 
network  survivability.  This  is  particularly  true  for  the  area  of  LEO  satellite  networks, 
which  serves  as  the  motivation  for  this  research. 
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CHAPTER  3 


METHODOLOGY 


3.1  Introduction 

This  chapter  explains  the  methodology  used  to  analyze  the  performance  of  the 
IRIDIUM®  system  and  discusses  the  design  and  testing  of  the  simulation  model.  Section 

3.2  discusses  the  different  methods  of  analysis  and  explains  the  use  of  simulation  for  this 
research.  Section  3.3  explains  how  the  scope  of  the  problem  was  limited  based  on  the 
time  and  computing  resources  available.  The  assumptions  used  in  developing  the 
simulation  model  are  discussed  in  Section  3.4.  Section  3.5  discusses  the  design  of  the 
simulation  model  and  briefly  explains  its  operation.  The  method  used  to  scale  the  model 
and  decrease  the  simulation  run  time  is  explained  in  Section  3.6.  The  verification  and 
validation  of  the  simulation  model  is  presented  in  Section  3.7.  The  algorithm  used  to 
select  critical  satellites  for  removal  is  developed  in  Section  3.8.  The  simulation's  input 
parameters  are  defined  in  Section  3.9.  Finally,  Section  3.10  presents  the  performance 
metrics  that  will  be  used  in  the  analysis. 

3.2  Method  of  Analysis 

There  are  three  possible  approaches  to  analyzing  a  problem  such  as  the 
performance  of  a  communications  network.  These  are  measurement,  analytical 
modeling,  and  simulation  [Jai91].  Simulation  is  the  most  appropriate  method  of 
determining  the  IRIDIUM®  network  performance.  Measurement  of  system  performance 
requires  that  the  system  both  exists  and  is  operational.  Since  the  IRIDIUM®  system  is 
not  yet  operational,  measurement  is  easily  ruled  out  as  a  method  of  analysis.  Both  the 
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dynamic  nature  and  the  size  of  the  IRIDIUM®  system  make  analytical  modeling 
impractical.  The  dynamic  nature  of  the  system  makes  it  difficult  to  determine  the  route, 
and  thus  the  end-to-end  delay,  between  two  sites.  The  large  number  of  nodes  in  the 
IRIDIUM®  system  make  it  difficult  to  analyze  it  as  a  network  of  queues.  Computer 
simulation  of  the  network  is  able  to  handle  both  the  dynamic  nature  and  the  size  of  the 
problem.  However,  even  simulation  has  limits  based  upon  the  speed  of  the  hardware  and 
software  used.  Stenger's  previous  research  on  IRIDIUM®  survivability  was  limited  due 
to  long  simulation  run  times  [Ste96].  One  of  the  objectives  of  this  research  is  to  develop 
a  faster  simulation  of  the  IRIDIUM®  network  to  allow  simulation  of  high  loading  levels 
in  reasonable  run  times. 

3.3  Scope  of  Problem 

The  scope  of  this  problem  must  be  limited  in  order  to  model  the  IRIDIUM® 
system  within  the  time  and  computing  resources  available.  The  scope  of  the  simulation 
must  be  complex  enough  to  provide  accurate  and  meaningful  results  and  at  the  same  time 
limited  enough  to  be  accomplished  with  the  resources  available.  There  are  several 
aspects  of  the  IRIDIUM®  system  where  the  scope  of  the  simulation  can  be  limited 
without  significantly  affecting  the  results  of  an  end-to-end  delay  analysis.  These  include 
call  setup  procedures,  handoff  procedures,  numbers  and  types  of  users,  and  types  of 
equipment  failures. 

3.3.1  Call  Setup  Procedures 

The  effect  of  call  setup  procedures  will  not  be  modeled  in  this  research.  As 
discussed  in  Chapter  2,  IRIDIUM®  call  setup  procedures  use  databases  distributed 
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throughout  the  gateways  to  locate  the  mobile  users.  The  focus  of  this  study  is  the  real 
time  communications  performance  of  the  IRIDIUM®  system.  Call  set  up  procedures  add 
some  delay  in  the  establishment  of  a  communications  link,  but  do  not  contribute  to  end- 
to-end  delay  once  the  link  is  established.  The  call  setup  procedures  also  contribute  to 
traffic  on  the  network.  However,  it  is  assumed  that  the  IRIDIUM®  call  setup  traffic  uses 
separate  channels  from  actual  voice  or  data  traffic.  The  call  setup  traffic  does  not 
contribute  to  the  end-to-end  delay  of  network  traffic  by  competing  for  network  resources. 
Modeling  the  call  setup  procedures  would  significantly  increase  the  complexity  of  the 
simulation  without  improving  the  end-to-end  delay  analysis. 

3.3.2  Handoff  Procedures 

This  research  will  account  for  satellite-to-satellite  handoffs,  but  will  not  model 
beam-to-beam  handoffs  within  a  satellite  footprint.  The  handoff  of  a  ground  station  link 
from  one  satellite  to  another  could  significantly  affect  end-to-end  packet  delay.  A 
satellite-to-satellite  handoff  will  affect  both  the  earth  to  satellite  propagation  delay  and 
the  shortest  path  to  the  receiving  earth  station.  A  beam-to-beam  handoff  will  have  almost 
no  effect  on  either  one  of  these  delay  components.  Modeling  each  beam  in  the 
IRIDIUM®  network  as  a  queue  would  require  3,168  queues,  while  modeling  only  the 
satellites  requires  66  queues.  It  is  expected  that  modeling  beam-to-beam  handoffs  will 
increase  the  runtime  of  the  simulation  without  necessarily  providing  better  end-to-end 
delay  measurements. 

3.3.3  Number  and  Types  of  Users 

The  IRIDIUM®  users  in  this  study  will  be  modeled  as  seven  stationary  earth 
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stations  and  no  mobile  users.  It  is  reasonable  to  model  mobile  IRIDIUM®  users  as  a 


stationary  earth  station.  As  discussed  in  Chapter  2,  the  velocity  of  a  LEO  satellite  is 
much  faster  than  that  of  a  mobile  user  in  an  airplane.  A  mobile  user  could  leave  the 
coverage  area  of  one  satellite  and  enter  that  of  another  satellite,  which  would  cause  a 
handoff  and  change  the  end-to-end  delay.  Since  the  satellites  are  traveling  much  faster 
than  mobile  users,  satellites  passing  overhead  will  cause  many  more  handoffs  than  users 
moving.  The  mobile  users  within  a  satellite  footprint  will  generate  traffic  for  that  satellite 
independent  of  each  other.  It  is  acceptable  to  model  this  group  of  independent  traffic 
sources  as  a  single  traffic  source  with  a  Poisson  mean  arrival  rate.  The  location  of  the 
seven  earth  stations  was  selected  so  that  they  were  distributed  between  150  degrees  east 
and  100  degrees  west  longitude  as  well  as  between  50  degrees  north  and  south  latitude. 
The  intent  of  this  was  to  have  traffic  sources  and  destinations  evenly  distributed 
throughout  the  network.  The  locations  of  the  earth  stations  are  summarized  in  Table  2. 


Table  2:  Earth  Station  Data 


City 

iFmimrn 

Latitude 

Altitude 

Rio  de  Janeiro 

-43.22 

-22.90 

0.01 

Melbourne 

144.97 

-37.80 

0.00 

Kansas  City 

39.13 

0.23 

Dhahran 

50.00 

27.00 

0.76 

116.47 

39.90 

0.18 

I  Berlin 

13.42 

52.53 

0.03 

18.37 

-33.93 

0.00 

There  will  also  be  no  attempt  to  model  traffic  between  mobile  IRIDIUM®  users  and 
PSTN  users. 


3.3.4  Types  of  Equipment  Failures 


There  are  numerous  types  of  equipment  failures  that  could  affect  end-to-end  delay 
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in  the  IRIDIUM®  network.  This  research  will  focus  on  the  complete  failure  of  satellite 
communication  nodes.  The  failure  of  a  satellite  will  result  in  the  loss  of  its 
communication  links  effectively  removing  it  from  the  network.  An  actual  satellite 
equipment  failure  would  more  likely  result  in  reduced  capability  than  in  complete  loss  of 
communications.  Complete  failure  of  a  satellite  will  analyze  the  survivability  of 
IRIDIUM®  under  a  worst  case  scenario.  If  the  system  is  able  to  maintain  acceptable 
end-to-end  delay  with  the  complete  satellite  failures,  it  will  certainly  be  able  to  perform 
adequately  under  conditions  of  reduced  capability. 

3.4  Assumptions 

The  simulation  model  was  developed  using  the  commercial  software  packages 
SATLAB  and  DESIGNER  by  Cadence  Design  Systems,  Inc.  [Cad95].  The  actual 
IRIDIUM®  specifications  were  used  whenever  possible  to  create  an  accurate  simulation. 
However,  it  was  necessary  to  make  several  assumptions  either  when  specific  data  on 
IRIDIUM®  was  not  published  in  open  literature,  or  when  it  was  necessary  to  simplify  the 
model.  The  rationale  for  these  assumptions,  as  well  as  their  effect  on  the  simulation 
accuracy,  is  explained  in  this  section. 

3.4.1  Packet  Size  and  Data  Structures 

The  basic  element  that  is  created  and  transmitted  through  a  network  in 
DESIGNER  is  termed  a  Data  Structure.  It  was  therefore  necessary  to  decide  how  to 
represent  the  voice  traffic  of  the  IRIDIUM®  system  using  Data  Structures.  The 
simulation  assumes  that  IRIDIUM®  voice  traffic  can  be  modeled  as  packet  voice  traffic. 
Since  the  voice  transmission  link  is  already  divided  into  TDMA  slots,  it  was  assumed  that 
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each  voice  packet  would  be  equivalent  to  one  uplink  TDMA  slot.  Each  Data  Structure  in 
DESIGNER  represents  one  voice  packet.  Using  this  assumption,  the  size  of  a  voice 
packet  can  be  calculated  using  the  structure  of  the  TDMA  frame. 

The  size  of  a  voice  packet,  representing  a  single  time  slot  of  the  TDMA  frame,  is 
calculated  to  be  432  bits.  The  specific  details  of  the  IRIDIUM®  TDMA  frame,  including 
the  number  of  framing  bits  and  the  length  of  a  user  time  slot,  are  not  published.  In 
addition,  the  type  of  voice  encoding  that  will  be  used  to  provide  acceptable  voice  quality 
at  4,800-bps  is  proprietary  and  is  not  published.  However,  it  is  not  difficult  to  calculate 
the  length  of  a  TDMA  time  slot  using  the  published  TDMA  frame  length  of  90-ms,  the 
burst  data  rate  of  50-kbps,  and  the  sustained  data  rate  of  4,800-bps.  It  is  also  easy  to 
show  that  the  known  TDMA  frame  structure  will  support  a  sustained  data  rate  of  4,800- 
bps.  Each  user  must  transmit  432  bits  in  a  90-ms  frame  to  achieve  a  data  rate  of  4,800- 
bps. 

4800  bpsx  90  ms  =  432  bits  (9) 

A  user  uplink  or  downlink  time  slot  with  a  burst  data  rate  of  50-kbps  is  8.64  ms. 


432  bits 


=  8.64  ms 


(10) 


50  kbps 

The  eight  user  time  slots  take  up  a  total  of  69.12-ms,  which  leaves  20.88-ms  of  the 
TDMA  frame  for  framing  bits  and  guard  time  slots.  A  possible  frame  structure  is  to  use  a 
framing  time  slot  twice  as  long  as  an  individual  user  time  slot.  This  would  result  in  864 
framing  bits  taking  up  17.28-ms.  Subtracting  this  value  from  the  20.88-ms  remaining  in 
the  TDMA  frame  leaves  3.6-ms  for  guard  time  slots.  This  can  be  divided  into  eight  400- 
ps  guard  time  slots  between  time  slots  in  the  frame,  and  two  200-ps  guard  time  slots  at 
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each  end  of  the  frame.  Although  the  exact  frame  structure  is  not  published  in  open 
literature,  this  approach  is  reasonable.  It  uses  4.6%  of  the  90-ms  frame  for  guard  time, 
and  utilizes  76.8%  of  the  frame  for  actual  data  bits. 


3.4.2  Packet  Arrival  Rate 

The  voice  packets  in  the  model  are  assumed  to  arrive  in  a  Poisson  manner  with  a 
maximum  arrival  rate  of  42,667  packets-per-second.  Recall  from  Section  3.3  that  each 
earth  station  represents  all  the  users  in  a  satellite  footprint.  A  Poisson  arrival  rate  was 
assumed  because  it  is  common  to  model  voice  communication  networks  with  M/M/1 
queues.  In  Section  2.7,  it  was  shown  that  each  satellite  has  a  maximum  of  3,840 
simultaneous  users.  Each  user  is  able  to  transmit  during  one  uplink  timeslot  for  each  90- 
ms  frame.  The  maximum  packet  arrival  rate  is  calculated  using  the  previous  assumption 
that  each  voice  packet  represents  one  uplink  time  slot. 


3840  packets 


=  42,667  packets  -  per  -  second 


(11) 


90 -ms 

The  minimum  time  between  packets  is  23.44-psec. 

3.4.3  Satellite  Processing  Delay 

The  satellite  processing  delay  is  assumed  to  be  a  Gaussian  random  variable  with  a 
mean  of  14-psec.  Although  it  is  common  to  model  voice  communications  networks 
using  M/M/1  queues,  the  use  of  an  exponential  service  time  did  not  seem  appropriate  in 
this  situation.  Since  each  voice  packet  is  assumed  to  be  the  same  size  it  is  reasonable  to 
expect  the  service  time  for  each  packet  to  be  approximately  equal.  The  use  of  a  Gaussian 
random  variable  for  satellite  processing  delay  provides  similar  delays  for  each  packet. 
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The  selection  of  14-|jsec  as  the  mean  processing  delay  is  explained  as  part  of  the  loading 
discussion  in  Section  3.4.4. 


3.4.4  Loading  Levels 

The  simulation  loading  level  represents  the  percent  utilization  of  the  satellite 
uplinks  for  each  earth  station.  The  simulation  was  run  at  different  loading  levels  by 
varying  the  arrival  rate  for  each  earth  station.  The  percent  of  uplink  utilization,  earth 
station  arrival  rates,  network  arrival  rates,  and  resulting  percent  processor  utilization  are 
summarized  in  Table  3.  For  example,  a  100%  loading  level  means  that  all  seven  earth 
stations  are  transmitting  at  the  maximum  packet  arrival  rate  of  42,667  packets-per- 
second. 


Table  3:  Earth  Station  Loading  Levels 


Uplink 

Utilization 

Earth  Station 
Arrival  Rate 
(packets-  per-sec) 

Network 

Arrival  Rate 
(packets-per-sec) 

Processor 

Utilization 

50% 

21334 

149338 

30% 

83% 

35556 

248892 

50% 

100% 

42667 

298669 

60% 

The  network  arrival  rate  is  calculated  by  multiplying  the  earth  station  arrival  rate  by  the 
number  of  earth  stations.  The  percent  utilization  of  the  satellite  switching  processor  in 
Table  3  is  calculated  using  Equation  12  where  X  is  the  earth  station  packet  arrival  rate  and 


|i  is  the  packet  service  rate. 


P 


(12) 


The  actual  processing  speed  of  the  IRIDIUM®  switching  processors  is  not  published  in 
open  literature.  As  presented  in  Section  3.4.3  the  mean  packet  processing  delay,  which  is 
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the  inverse  of  the  service  rate,  is  assumed  to  be  14-psec.  The  assumed  service  rate  of  the 
switching  processor  should  be  fast  enough  to  handle  the  maximum  uplink  traffic  load 
plus  any  ISL  traffic  with  an  acceptable  queuing  delay.  In  a  typical  delay  versus  loading 
curve,  as  shown  in  Figure  7,  the  delay  begins  to  increase  exponentially  at  approximately 
70%  load.  In  order  to  keep  the  switching  processor  utilization  below  70%,  the  processor 
load  generated  by  the  uplink  traffic  alone  must  be  below  70%.  How  far  below  70%  this 
must  be  depends  upon  the  amount  of  ISL  traffic  on  the  network.  It  was  desired  that  the 
baseline  simulation,  with  no  satellites  removed  from  the  constellation,  could  accept  100% 
of  the  uplink  traffic  from  all  seven  earth  stations.  Under  this  traffic  load,  the  desired 
performance  was  defined  as  all  end-to-end  delays  below  400-ms  and  no  packet  rejections. 


Figure  7:  Typical  Delay  vs.  Loading  Curve 


Pilot  tests  with  different  service  rates  showed  that  the  baseline  simulation  performed 
acceptably  when  the  maximum  uplink  traffic  caused  no  more  than  60%  processor 
utilization.  The  service  rate  required  to  achieve  this  is  calculated  as  71,112  packets-per- 
second  using  Equation  12  where  p  equals  0.6  and  X  equals  42,667  packets-per-second. 
The  inverse  of  this  service  rate  is  the  assumed  mean  satellite  processing  delay  of  14-psec. 
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3.4.5  Traffic  Distribution 


The  simulation  is  run  with  different  traffic  distributions  to  represent  different 
calling  patterns.  The  traffic  distribution  is  initially  assumed  to  be  uniform.  In  this  case 
the  source  and  destination  of  each  packet  is  randomly  generated  with  equal  probability 
for  all  earth  stations.  In  addition,  the  source  and  destination  nodes  of  each  packet  are 
assumed  to  be  different.  This  traffic  distribution  is  summarized  in  Table  4. 


Table  4:  Uniform  Traffic  Distribution 


Location 

Transmit 

Probability 

Destination  Probability  I 

Rio  de  Janeiro 

Melbourne 

Kansas  City 

Dhahran 

Beijing 

Berlin 

Capetown 

Rio  de  Janeiro 

0.143 

0 

0.167 

0.167 

0.167 

0.167 

0.167 

0.167 

Melbourne 

0.143 

0.167 

0 

0.167 

0.167 

0.167 

0.167 

0.167 

Kansas  City 

0.143 

0.167 

0.167 

0 

0.167 

0.167 

0.167 

0.167 

Dhahran 

0.143 

0.167 

0.167 

0.167 

0 

0.167 

0.167 

0.167 

BHH 

0.143 

WER5M 

0.167 

0.167 

0 

0.167 

0.167 

Berlin 

0.143 

0.167 

0.167 

0.167 

0.167 

0.167 

0 

0.167 

Capetown 

0.143 

0.167 

0.167 

0.167 

0.167 

0.167 

0.167 

0 

An  actual  communications  network  is  not  likely  to  have  a  uniform  traffic  distribution.  In 
this  respect,  the  assumption  of  a  uniform  traffic  distribution  does  not  provide  an  accurate 
representation  of  the  IRIDIUM®  system.  However,  since  the  IRIDIUM®  network  is  not 
yet  operational  there  are  no  existing  statistics  on  actual  traffic  distributions.  The 
assumption  of  a  uniform  traffic  distribution  serves  as  a  baseline  in  the  simulation.  The 
assumed  non-uniform  traffic  distributions  will  be  compared  to  this  baseline  in  order  to 
measure  their  effect  on  network  performance. 

The  traffic  distribution  is  next  assumed  to  be  non-uniform  with  a  low  overall 
network  load.  The  non-uniform  distribution  is  intended  to  simulate  a  high  traffic  load 
between  two  geographic  regions  of  the  world.  These  two  earth  stations  transmit  more 
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often  than  the  other  earth  stations,  and  they  transmit  to  each  other  more  often  than  to  the 
other  earth  stations.  The  remaining  earth  stations  transmit  with  uniformly  distributed 
source  and  destination.  The  two  high  traffic  locations  were  selected  as  Kansas  City  and 
Dhahran.  This  non-uniform  traffic  distribution  is  summarized  in  Table  5. 


Table  5:  Non-Uniform  Traffic  Distribution  Low  Load 


Location 

T  ransmlt 
Probability 

Destination  Probability  j 

Rio  de  Janeiro 

Melbourne 

Kansas  City 

Dhahran 

Beijing 

Berlin 

Capetown 

Rio  de  Janeiro 

0.100 

0 

0.167 

0.167 

0.167 

0.167 

0.167 

0.167 

Melbourne 

0.100 

0.167 

0 

0.167 

0.167 

0.167 

0.167 

0.167 

Kansas  City 

0.250 

0.067 

0.067 

0 

0.667 

0.067 

0.067 

0.067 

Dhahran 

0.250 

0.067 

0.067 

0.667 

0 

0.067 

0.067 

0.067 

Beijing 

0.100 

0.167 

0.167 

0.167 

0.167 

0 

0.167 

0.167 

Berlin 

0.100 

0.167 

0.167 

0.167 

0.167 

0.167 

0 

0.167  . 

Capetown 

0.100 

0.167 

0.167 

0.167 

0.167 

0.167 

0 

In  order  to  compare  this  traffic  distribution  to  the  uniform  case,  the  simulation  is  run  with 
a  network  arrival  rate  of  149,338  packets-per-second.  As  shown  in  Table  3  this  is  the 
same  network  traffic  load  as  that  used  in  the  50%  uplink  loading  level.  The  different 
transmission  probabilities  in  the  non-uniform  traffic  distribution  result  in  different  values 
for  uplink  loading  level,  earth  station  arrival  rate,  and  processor  utilization.  These  values 
are  summarized  in  Table  6.  It  is  important  to  note  that  the  redistribution  of  traffic  does 
not  cause  an  uplink  utilization  greater  than  100%. 


Table  6:  Non-Uniform  Low  Loading  Levels 


Transmit 

Probability 

Uplink  Utilization 

Earth  Station 
Arrival  Rate 
(packets- per-sec) 

Processor 

Utilization 

0.25 

87% 

37297 

52% 

0.1 

35% 

14919 
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The  final  assumed  traffic  distribution  is  a  non-uniform  distribution  with  a  medium 


overall  network  load.  As  with  the  previous  non-uniform  distribution,  Kansas  City  and 
Dhahran  generate  a  higher  percentage  of  the  network  traffic.  The  network  arrival  rate  is 
assumed  to  be  248,892  packets-per-second.  This  is  the  same  arrival  rate  as  that  used  in 
the  83%  uplink  loading  case,  which  allows  the  results  to  be  compared  with  that  uniform 
traffic  distribution.  This  traffic  distribution  is  shown  in  Table  7. 


Table  7:  Non-Uniform  Traffic  Distribution  Medium  Load 


Location 

Transmit 

Probability 

!  Destination  Probability  I 

Rio  de  Janeiro 

Melbourne 

Kansas  City 

Dhahran 

Beijing 

Berlin 

Capetown 

Rio  de  Janeiro 

0.136 

0 

0.167 

0.167 

0.167 

0.167 

0.167 

0.167 

Melbourne 

0.136 

0.167 

0 

0.167 

0.167 

0.167 

0.167 

0.167 

Kansas  City 

0.161 

0.067 

0.067 

0 

0.667 

0.067 

0.067 

0.067 

Dhahran 

0.161 

0.067 

0.067 

0.667 

0 

0.067 

0.067 

0.067 

0.136 

0.167 

0.167 

0.167 

0.167 

0 

0.167 

Berlin 

0.136 

0.167 

0.167 

0.167 

0.167 

0.167 

0 

0.167 

Capetown 

0.136 

0.167 

0.167 

0.167 

0.167 

0.167 

0.167 

0 

The  uplink  loading  level,  packet  arrival  rate,  and  processor  utilization  associated  with 
these  transmit  probabilities  is  shown  in  Table  8. 


Table  8:  Non-Uniform  Medium  Loading  Levels 


T  ransmit 
Probability 

Uplink  Utilization 

Earth  Station 
Arrival  Rate 
(packets-per-sec) 

Processor 

Utilization 

0.161 

93% 

40032 

56% 

0.136 

79% 

33815 

48% 

3.4.6  Routing  Algorithm 


The  simulation  assumes  that  packets  are  routed  from  source  to  destination  using  a 
"self-healing"  Dijkstra  routing  algorithm.  The  algorithm  calculates  the  shortest  path  from 
source  to  destination  based  upon  the  current  satellite  connectivity.  It  is  a  "self-healing" 
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algorithm  because  it  recalculates  the  shortest  path  when  the  connectivity  between  source 
and  destination  changes.  The  change  in  connectivity  could  be  the  result  of  the  moving 
satellite  constellation,  or  the  result  of  removing  satellites  from  the  constellation.  The 
Dijkstra  routing  algorithm  assumes  that  all  nodes  have  instantaneous  knowledge  of  the 
health  and  connectivity  of  other  nodes.  No  attempt  is  made  to  model  the  overhead 
associated  with  updating  the  satellite  routing  tables.  The  Dijkstra  algorithm  calculates 
the  shortest  path  based  only  upon  cumulative  propagation  distance.  The  actual  routing 
algorithm  used  in  IRIDIUM®  is  proprietary  and  is  not  published.  It  is  likely  that  the 
actual  algorithm  has  the  capability  to  balance  network  load  by  routing  around  heavily 
loaded  satellites.  The  actual  system  must  also  have  some  overhead  associated  with 
updating  the  satellite  routing  tables.  In  this  respect,  the  Dijkstra  algorithm  introduces 
some  error  into  the  simulation's  representation  of  the  actual  IRIDIUM®  system. 
However,  the  Dijkstra  algorithm  has  the  advantage  that  it  greatly  simplifies  the  design  of 
the  simulation  model.  The  decision  was  made  that  the  error  introduced  by  assuming  a 
Dijkstra  routing  algorithm  is  acceptable  based  upon  the  gains  realized  in  simplification  of 
the  design. 

3.4.7  ISL  Establishment 

Each  IRIDIUM®  satellite  is  capable  of  having  up  to  four  ISLs  with  adjacent 
satellites.  A  satellite  can  establish  ISLs  to  the  forward  and  aft  satellites  in  the  same 
orbital  plane.  A  satellite  can  also  establish  one  ISL  to  a  satellite  in  each  adjacent  orbital 
plane  if  the  horizontal  pointing  angle  between  the  satellites  is  within  the  steering  range  of 
the  antenna.  Using  a  reference  of  zero  degrees  parallel  to  the  equator,  the  ISL  antennas 
are  assumed  to  have  a  mean  pointing  angle  of  ±  50  degrees  with  a  steering  range  of  ± 


39 


22.5  degrees  from  the  mean  pointing  angle.  The  actual  steering  capabilities  of  the 
IRIDIUM®  ISL  antennas  are  not  published.  As  discussed  in  Chapter  2,  a  nominal 
horizontal  azimuth  of  ±  45  to  50  degrees  with  an  antenna  steering  range  of  30  to  45 
degrees  is  sufficient  to  maintain  inter-orbital  links  between  latitudes  of  50  to  60  degrees 
north  and  south.  Several  pilot  tests  of  the  model  were  made  to  determine  a  mean  pointing 
angle  and  steering  range  combination  that  performed  acceptably  in  the  model.  A  mean 
pointing  angle  of  50  degrees  with  a  steering  range  of  45  degrees  was  the  best 
combination.  This  combination  allowed  the  model  to  establish  ISLs  between 
approximately  ±  60  degrees  latitude. 

3.4.8  Delay  Calculations 

The  end-to-end  packet  delay  in  this  model  is  calculated  using  Equation  13. 

T Packet  ~  T access  ^uplink  (W  ~ 0' ^ cross  +  ^  'Tsa,  +T(lm/nlink  (13) 

T access  is  the  access  delay  associated  with  the  multiple  access  technique.  Tupiink,  Tcross,  and 
Tdowniink  are  the  propagation  delays  for  the  respective  links.  Tsat  is  the  processing  and 
queuing  delay  a  packet  experiences  at  a  satellite  node,  and  N  is  the  number  of  satellite 
nodes  in  the  path.  The  effects  of  Doppler  shift  are  ignored  in  the  calculation  of  end-to- 
end  packet  delay. 

The  packet  access  delay,  Taccess,  is  assumed  to  be  TDMA  access  delay  with  a  value 
of  53.64-ms.  The  technique  for  calculating  Taccess  for  an  FDMA  or  TDMA  system  is  well 
known  and  the  equations  are  widely  published.  The  FDMA  access  delay  is  simply  the 
packet  transmission  time  since  the  FDMA  channel  is  always  available  as  given  in 
Equation  14. 
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j,  _  Number  of  Bits  per  Packet 
FDm  Channel  Transmission  Rate  (bps) 

The  TDMA  access  delay  depends  on  both  the  packet  transmission  time  and  the  average 
waiting  time  for  a  TDMA  slot.  Under  the  assumption  that  each  TDMA  slot  is  large 
enough  to  transmit  one  packet,  the  packet  transmission  time  is  simply  the  TDMA  slot 
time.  The  average  time  a  user  has  to  wait  for  a  TDMA  time  slot  is  one  half  of  the  TDMA 
frame  length.  The  TDMA  access  delay  is  described  by  Equation  15  where  Tf  is  the 
TDMA  frame  length  and  Tslot  is  the  TDMA  slot  time. 

Ttdma  ~  —  +  Tslot  (15) 

The  method  for  calculating  access  delay  in  a  system  like  IRIDIUM®  that  uses 
both  TDMA  and  FDMA  is  not  widely  published.  However,  an  analysis  of  the  call  setup 
procedure  indicates  that  the  IRIDIUM®  access  delay  is  simply  the  TDMA  access  delay. 
As  discussed  in  Section  2.7,  each  cell  in  the  IRIDIUM®  system  has  20  frequency 
channels  with  four  TDMA  users  per  frequency  channel.  When  a  subscriber  unit  goes  off 
hook,  it  will  receive  a  dial  tone  after  a  slight  delay  similar  to  that  experienced  with  a 
common  cordless  telephone.  This  delay  is  caused  by  the  time  necessary  to  assign  the 
user  a  frequency  channel  and  it  does  not  contribute  to  the  end-to-end  packet  delay.  It  is 
logical  to  assume  that  the  user  is  assigned  both  a  frequency  channel  and  a  full  duplex 
TDMA  time  slot  when  he  receives  dial  tone.  If  a  TDMA  time  slot  is  not  available  to 
assign  to  the  user,  the  frequency  channel  could  not  be  assigned.  At  this  point,  the  user 
can  be  considered  one  of  four  users  sharing  a  TDMA  channel  and  the  access  delay  can  be 
calculated  as  TDMA  access  delay.  Recall  from  above  that  the  IRIDIUM®  TDMA  frame 
length  is  90  ms,  and  the  slot  time  is  8.64-ms.  Based  on  the  assumption  that  each  packet  is 
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the  same  length  as  one  TDMA  frame  slot,  the  TDMA  access  delay  is  calculated  53.64-ms 
using  Equation  15. 

Propagation  delay  is  calculated  using  the  formula  distance/speed  of  light. 
Atmospheric  effects  are  ignored  in  the  calculation  of  propagation  delay.  The  minimum 
distance  for  an  uplink  or  downlink  is  the  satellite  altitude  of  780-km.  The  minimum 
values  of  Tupiink  and  Tdowniink  are  calculated  as  approximately  2.05-ms  using  Equation  16. 


Distance  to  Satellite 


780  km 


=  2.05  ms 


(16) 


Speed  of  Light  3x10 s  m/s 

The  maximum  distance  for  an  uplink  or  downlink  is  calculated  as  2,465. 16-km  using 
Equation  4  from  Chapter  2.  The  equation  is  repeated  here  for  ease  of  reference. 


d‘(R’+h)fSr^^> 


(17) 


The  maximum  values  of  Tupn„k  and  Tdowniink  are  calculated  as  8.22-ms  using  Equation  17. 
The  values  of  Tupu„k  and  Tdowniink  calculated  by  the  model  use  the  actual  distance  between 
the  ground  station  and  the  satellite.  The  propagation  delay  Tcr0ss  varies  because  the 
distance  between  satellites  in  adjacent  orbits  changes  at  different  latitudes.  Below 
latitudes  of  60  degrees,  where  ISLs  can  be  maintained  between  adjacent  orbital  planes, 
the  distance  between  satellites  varies  between  3,270  and  4,480-km  [Wer95].  The 
distance  between  satellites  in  the  same  orbital  plane  is  4,030-km  [Wer95].  Using  an 
average  distance  of  4,000-km  between  satellites  results  in  an  average  Tcrowof  13.33-ms. 


Crosslink  Distance 
Speed  of  Light 


4000  km 
3xl08  mis 


13.33  ms 


(18) 
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The  values  of  Tcross  calculated  by  the  model  use  the  actual  line-of-sight  distance  between 
the  satellites. 

The  satellite  processing  and  queuing  delay,  Tsati  depends  on  both  the  satellite 
processing  delay  and  the  loading  level  of  the  current  satellite.  As  discussed  in  Section 
3.4.3  the  satellite  processing  delay  is  assumed  to  be  14-ps.  The  model  calculates  the 
queuing  delay  for  each  node  assuming  a  single  server  First  In  First  Out  (FIFO)  queue  for 
each  satellite. 

3.4.9  Network  Access 

An  earth  station  is  assumed  to  have  access  to  the  satellite  network  when  a  satellite 
above  the  minimum  elevation  angle  of  8.2  degrees  is  visible  to  the  earth  station.  The 
uplink  from  this  earth  station  to  the  satellite  is  assumed  to  be  always  available.  No 
attempt  is  made  to  model  the  effect  of  local  terrain  or  buildings  on  a  user’s  ability  to 
access  the  satellite.  The  maximum  traffic  load  generated  by  an  earth  station,  as  discussed 
in  Section  3.4.4,  will  not  exceed  the  uplink  capacity  of  a  satellite.  Therefore,  the 
simulation  makes  no  attempt  to  model  the  effects  of  blocking  probability  on  a  user’s 
ability  to  access  the  network. 

3.4.10  Queue  Size 

The  maximum  queue  size  for  each  satellite  is  assumed  to  be  4,000.  The  intent  of 
limiting  the  queue  size  is  to  reject  packets  from  the  network  that  will  clearly  have  an  end- 
to-end  delay  in  excess  of  400-ms.  The  maximum  end-to-end  delay  that  a  packet  will 
experience  is  given  by  Equation  19  where  N  is  the  number  of  satellites  in  the  path  and  Q 
is  the  maximum  queue  length. 
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TMwc  =  ^access  +  ^uplink  +  (N  ~  l)'  Tcross  +  N  •  Tsg,  +  TdomUni  +  N  •  (Q- 1)-  TM  (19) 
Pilot  tests  of  the  simulation  showed  that  no  more  than  seven  satellites  were  in  any  path. 
The  value  of  Tmox  is  plotted  for  different  queue  sizes  in  Figure  8.  The  plot  assumes  the 
maximum  values  of  T access  -  53.64-ms,  Tupiink  “  T downlink  -  8.22-ms,  Tcross  -  14.93-ms,  Tsat 
“  14-ltsec  and  N  —  7.  The  plot  shows  that  the  maximum  end-to-end  delay  with  a  queue 

size  of  4,000  is  over  500-ms.  This  justifies  the  assumption  of  a  maximum  queue  size 
equal  to  4,000. 


3.5  Model  Design 

SATLAB  is  a  satellite  simulation  tool  that  is  used  to  design  and  model  satellite 
constellations.  It  uses  the  orbital  parameters  of  the  satellites  to  calculate  their  position 
over  a  specified  period  of  time.  SATLAB  also  determines  if  satellites  have  line  of  sight 
visibility  to  other  satellites  and  earth  stations.  The  information  calculated  by  SATLAB  is 
stored  in  a  visibility  matrix,  an  elevation  matrix,  and  a  distance  matrix.  DESIGNER  is  a 
network  simulation  tool  that  is  used  to  model  and  analyze  communication  networks. 
DESIGNER  is  able  to  interface  with  SATLAB  through  the  BoNES  SATLAB  Interface 
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Module  (BSIM).  At  specified  intervals,  DESIGNER  receives  the  current  visibility, 
elevation,  and  distance  matrices  from  SATLAB.  This  information  is  used  in  DESIGNER 
to  develop  a  snapshot  of  the  IRIDIUM®  system  connectivity.  DESIGNER  is  then  able  to 
treat  the  network  as  a  static  network  for  the  purposes  of  the  routing  algorithm  and  delay 
calculations.  Frequent  updates  between  SATLAB  and  DESIGNER  make  it  possible  to 
use  static  network  analysis  techniques  to  model  the  dynamic  aspects  of  the  IRIDIUM® 
system.  The  combination  of  SATLAB  and  DESIGNER  is  well  suited  for  the  simulation 
of  the  IRIDIUM®  LEO  satellite  network. 

The  top  level  of  the  simulation  has  two  main  modules,  the  Positioning  module 
and  the  Communication  module,  as  shown  in  Figure  9. 


Iridium  Model  1  [  1 8-Mar-1 998  1 4:51 :47  ] 


[POSITIONING] 


0  Relative  Order 


JM-Pf-p  ElOppI 


Start— D 


INITIALIZATION 


UPDATE 
NODE  POSITION 


ITp  Year  fp  Month  tp  Day  0  Number  of  Nodes 

'  t“P  Hour  Ifa  Minute  tp  Second  0  Number  of  Earthstations 
0  Latitude  Table  Memory 
0  Altitude  Table  Memory 


Ifp  NodePositionUpdate  Time  Delay 
0  Distance  table  memory 
0  Elevation  Table  Memory 
0  Routing  Table  Memory 
0  Visibility  Table  memory 


[COMMUNICATION] 


0  Node  resource 


EARTH 


SPACE 


tP  Antenna  mean  value 
?P  Antenna_angle 

tP  Var 
fp  Mean 
fp  Factor 


Figure  9:  Simulation  Top  Level 
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The  purpose  of  the  Positioning  module  is  to  interface  with  SATLAB  and  develop  the 
routing  table.  The  module  periodically  updates  the  routing  table  in  order  to  simulate  the 
constantly  changing  connectivity  of  the  IRIDIUM®  network.  The  purpose  of  the 
Communication  module  is  to  generate  packets,  route  them  from  source  to  destination,  and 
collect  information  for  analysis.  The  primary  data  generated  for  each  packet  is  end-to- 
end  packet  delay.  It  is  also  possible  to  trace  the  path  that  a  packet  takes  through  the 
network.  The  Positioning  module  begins  by  executing  the  Initialization  block.  This 
block  gets  the  number  of  earth  stations  from  SATLAB  and  initializes  SATLAB  to  the 
epoch  start  time.  Next  the  Update  Node  Position  block  requests  the  distance,  elevation, 
and  visibility  matrices  from  SATLAB.  These  values  are  used  to  develop  the  shortest  path 
routing  table.  The  Update  Node  Position  block  executes  periodically,  as  specified  by  the 
Node  Position  Update  Time  Delay,  and  recalculates  the  routing  table. 

The  Earth  Station  block  generates  the  packets  with  a  Poisson  arrival  rate.  For  the 
purposes  of  the  simulation,  the  packet  is  actually  a  data  structure  with  fields  summarized 
in  Table  9.  The  Sequence  Number  is  a  counter  that  sequentially  numbers  the  packets. 
The  Source,  Destination,  Current  Node,  and  Next  Node  fields  are  used  to  determine  the 
route  and  to  determine  if  the  packet  has  reached  its  destination.  The  Current  Node  or 
Next  Node  fields  can  also  be  used  to  trace  a  packet's  path  through  the  network.  TNOW  is 
the  simulation  run  time  in  seconds.  The  Delay  field  is  incremented  by  various  modules 
as  the  packet  traverses  the  network  and  it  measures  end-to-end  packet  delay.  The  Hop 
Count  field  is  incremented  at  each  node  in  the  path  from  Source  to  Destination.  Once  the 
packet  is  generated,  it  is  passed  to  the  Routing  Selection  block. 
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Table  9:  Data  Structure  Fields 


Field  Name 

Type 

Description 

Sequence  Number 

Integer 

Sequentially  number  packets 

Source 

Integer 

Node  sending  packet 

Destination 

Integer 

Destination  of  packet 

Current  Node 

Integer 

Current  location  of  packet 

Next  Node 

Integer 

Next  node  in  path  to  destination 

TNOW 

Real 

Simulation  run  time 

Delay 

Real 

Cumulative  end  to  end  delay 

Hop  Count 

Integer 

Cumulative  number  of  nodes  in  path 

The  Routing  Selection  block  reads  the  Current  Node  and  Destination  fields.  It 
then  accesses  the  routing  table  to  determine  the  next  node  in  the  path.  The  block  updates 
the  Next  Node  field,  increments  the  Hop  Count  field,  and  passes  the  packet  to  the  Space 
block. 

The  Space  block  determines  if  the  next  link  is  satellite-to-satellite,  earth-to- 
satellite,  or  satellite-to-earth  based  upon  the  Current  Node  and  Next  Node  fields.  A 
different  block  is  used  to  calculate  the  delay  for  each  type  of  link.  The  delay  for  both  a 
satellite-to-satellite  link  and  a  satellite  to  earth  link  are  calculated  based  upon  propagation 
delay,  and  the  satellite  processing  and  queuing  delay.  The  delay  for  an  earth-to-satellite 
link  is  calculated  using  an  earth  station  processing  delay,  TDMA  access  delay,  and 
propagation  delay.  The  Space  block  receives  the  delay  calculation  from  the  appropriate 
block  and  updates  the  Delay  field  in  the  packet.  It  then  passes  the  packet  to  the 
Destination  Reached  block. 

The  Destination  Reached  block  reads  the  Next  Node  and  Destination  fields  to 
determine  if  the  packet  has  reached  its  destination.  If  the  fields  are  the  same,  the  packet 
has  reached  its  destination  and  it  stops  traversing  the  network.  If  they  are  not  the  same, 
the  Next  Node  field  is  written  to  the  Current  Node  field.  The  packet  is  then  passed  to  the 
Routing  Selection  block.  The  packet  will  continue  to  cycle  through  the  Routing 
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Selection,  Space,  and  Destination  Reached  blocks  until  the  Destination  and  Current  Node 
fields  match. 

3.6  Simulation  Scaling 

A  simulation  in  DESIGNER  that  attempts  to  model  the  actual  traffic  load  of  the 
IRIDIUM®  network  will  run  very  slowly.  Stenger’s  previous  analysis  of  the  IRIDIUM® 
network  was  limited  by  long  simulation  times  to  two  earth  stations  transmitting  at  an  1 1% 
uplink  loading  level.  Even  at  this  low  loading  level,  the  simulation  ran  for  two  to  three 
weeks  to  simulate  fifteen  minutes  of  real  time.  One  of  the  goals  of  this  research  is  to 
evaluate  the  IRIDIUM  ®  system  at  high  loading  levels.  This  can  only  be  accomplished 
with  the  computing  resources  available  by  improving  the  simulation  speed. 

Several  pilot  tests  of  the  simulation  were  conducted  to  determine  which 
parameters  had  the  greatest  effect  on  run  time.  First,  the  simulation  was  mn  with  a  low 
loading  level  and  the  node  update  time  was  varied  from  1-s  to  180-s.  Since  the 
simulation  must  pass  data  from  S  ATLAB  to  DESIGNER  at  each  node  update  time,  it  was 
expected  that  this  parameter  would  effect  the  run  time.  These  pilot  tests  revealed  that 
simulations  with  a  node  update  time  above  20-seconds  ran  at  approximately  the  same 
speed.  The  node  update  time  did  not  significantly  increase  the  simulation  runtime  unless 
it  was  below  20-seconds.  Next,  the  simulation  was  run  with  a  fixed  node  update  time  of 
30-seconds  and  varying  loading  levels.  This  revealed  that  the  simulation  run  time 
increased  in  direct  proportion  to  the  number  of  packet-per-second  generated  in  the  model. 
Based  on  this,  the  decision  was  made  to  scale  the  simulation  to  model  a  percentage  of  the 
actual  traffic  load. 
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Modeling  a  percentage  of  the  actual  traffic  load  must  be  accomplished  in  a 
manner  that  does  not  change  the  simulation’s  calculation  of  end-to-end  delay.  All  aspects 
of  the  simulation  used  to  calculate  delay  must  be  scaled  by  the  same  factor.  Dividing  the 
arrival  rate  X  by  a  factor  F  scales  the  traffic  load.  Since  the  packet  inter-arrival  time  is 
the  inverse  of  X,  scaling  the  arrival  rate  effectively  multiplies  the  inter-arrival  time  by  F. 
In  order  to  apply  the  scaling  factor  to  all  aspects  of  the  model  all  times  in  the  model  must 
be  multiplied  by  the  same  factor  F.  The  times  that  contribute  to  the  end-to-end  delay  are 
processing  delay,  propagation  delay,  and  queuing  delay.  The  processing  delay,  which  is 
the  inverse  of  the  service  rate  p,  is  an  input  parameter  to  the  simulation.  This  time  is 
easily  multiplied  by  the  scaling  factor  F.  The  propagation  delay  of  each  link  is  also 
multiplied  by  the  scaling  factor.  The  simulation  calculates  the  queuing  delay  at  each 
node.  The  average  service  time  Tav,  which  includes  both  queuing  delay  and  processing 
delay,  is  given  by  Equation  20. 


1 


(20) 


The  average  queuing  delay  W  is  obtained  by  subtracting  the  average  processing  delay 
from  Tav.  This  is  shown  in  Equation  21. 


W 


1 

jU  —  A 


(21) 


Note  that  both  p  and  X  have  already  been  scaled  by  a  factor  of  1/F.  Therefore  the 
queuing  delay  W  calculated  by  the  simulation  will  already  be  multiplied  by  the  scaling 
factor  F.  The  cumulative  end-to-end  delay  calculated  for  each  packet  in  the  simulation 
will  be  the  actual  delay  multiplied  by  the  scaling  factor  F.  In  order  to  analyze  this  delay 
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in  terms  of  real  time  communication  constraints,  it  must  be  converted  back  into  real  time. 
This  is  accomplished  by  dividing  the  delay  field  of  each  packet  by  the  scaling  factor 
when  the  packet  reaches  its  destination. 

Several  pilot  tests  of  the  simulation  were  conducted  to  determine  the  effect  of  the 
scaling  factor.  First,  the  simulation  was  run  both  scaled  by  a  factor  of  1 ,000  and  non- 
scaled  to  ensure  that  the  scaling  factor  did  not  change  the  output  of  the  model.  This  pilot 
test  was  conducted  with  two  earth  stations  for  60  seconds  of  simulation  time.  The 
average  end-to-end  delay  of  all  packets  in  the  scaled  test  was  120.87-ms  with  a  standard 
deviation  of  3.32-ms.  The  non-scaled  test  produced  an  average  delay  of  120.86-ms  with 
a  standard  deviation  of  0.3-ms.  The  lower  standard  deviation  in  the  non-scaled  test  can 
be  explained  by  the  fact  that  approximately  1 ,000  times  as  many  packets  were  generated. 
Next,  the  simulation  was  run  with  different  scaling  factors  to  determine  a  suitable  value 
of  F.  These  pilot  tests  were  conducted  with  all  seven  earth  stations  transmitting  at  a 
100%  link  load.  With  a  scaling  factor  of  10,000,  the  simulation  ran  for  approximately 
two  hours  to  simulate  40  minutes  of  real  time.  Recall  that  Stenger's  previous  model  ran 
for  over  two  weeks  to  simulate  two  earth  stations  transmitting  at  an  1 1%  link  load  for  15 
minutes  of  real  time.  The  simulation  scaling  results  in  a  significant  improvement  in  the 
simulation  run  time  that  will  allow  the  system  to  be  evaluated  at  high  loading  levels. 

3.7  Model  Verification  and  Validation 

The  simulation  was  tested  thoroughly  to  ensure  that  it  accurately  modeled  the 
IRIDIUM®  network.  The  model  verification  included  tests  to  ensure  that  the  model 
design  was  sound.  The  model  validation  consisted  of  tests  to  determine  if  the  outputs  of 
the  model  provided  an  accurate  representation  of  the  IRIDIUM®  system. 
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3.7.1  Verification 


The  verification  of  the  model  was  performed  at  two  levels.  First,  the  individual 
blocks  used  in  the  model  were  tested  to  ensure  that  they  were  performing  as  expected. 
Then  the  entire  model  was  tested  to  determine  if  the  complete  model  was  functioning 
properly.  In  addition  to  these  two  levels  of  testing,  DESIGNER  has  built  in  functions 
that  check  for  errors  each  time  a  block  is  saved  in  the  model.  These  functions  ensure  that 
input  and  output  parameters  of  blocks  are  assigned  with  the  correct  variable  types.  They 
also  check  for  missing  connections  between  blocks  in  a  module.  DESIGNER  will  not 
allow  a  simulation  to  be  run  if  it  does  not  pass  these  checks. 

The  verification  of  the  individual  blocks  revealed  that  the  TDMA  Access  Delay 
block  provided  with  SATLAB  was  not  functioning  as  expected.  Increasing  the  packet 
arrival  rate  resulted  in  an  exponentially  increasing  access  delay.  As  a  result,  access  delay 
could  become  the  major  delay  factor  in  end-to-end  packet  delay.  An  examination  of  the 
C  code  used  in  the  TDMA  Access  Delay  block  showed  that  the  formulas  used  to  calculate 
access  delay  assumed  an  infinite  user  population.  In  the  actual  IRIDIUM®  system  the 
number  of  users  is  limited  based  on  the  TDMA  frame  structure  and  the  number  of 
frequency  channels  available.  If  all  of  the  available  frequency  channels  and  their 
associated  TDMA  time  slots  are  in  use  then  additional  users  will  be  blocked  from  the 
system.  Additional  attempts  to  access  the  system,  above  the  system  capacity,  will  not 
contribute  to  the  packet  access  delay  for  those  users  already  assigned  frequency  and  time 
slots.  For  this  reason,  the  TDMA  Access  Delay  block  was  replaced  with  a  fixed  delay 
time  of  53.64-ms  as  discussed  in  Section  3.4.8. 
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The  verification  of  the  entire  model  consisted  of  varying  the  inputs  to  the  model 
and  determining  if  they  had  the  expected  effect  on  model  outputs.  In  addition  to  model 
outputs,  the  path  that  a  packet  took  through  the  network  was  examined.  The  effect  of 
changing  inputs  was  tested  to  determine  if  the  logic  of  the  entire  model  was  sound.  The 
path  was  examined  to  ensure  that  the  routing  algorithm  was  functioning  properly  and  that 
the  Communication  module  was  receiving  accurate  information  from  the  Positioning 
module. 

The  test  of  the  model  inputs  and  outputs  demonstrated  that  the  logic  of  the  model 
was  sound.  The  inputs  tested  were  packet  arrival  rate,  traffic  distribution,  and  satellite 
removal.  The  test  of  packet  arrival  rate  measured  the  number  of  packets  generated  in  the 
simulation  to  ensure  that  the  traffic  generator  was  performing  correctly.  It  also  measured 
the  average  end-to-end  delay  to  ensure  that  it  increased  with  heavier  loads  as  expected. 
The  test  of  the  traffic  distribution  counted  the  number  of  packets  transmitted  and  received 
at  each  earth  station  for  each  traffic  distribution.  The  results  were  compared  to  the 
uniform  and  non-uniform  traffic  distribution  tables  in  Section  3.4.5  to  ensure  proper 
operation.  The  test  of  satellite  removal  began  by  determining  the  path  that  a  packet  took 
between  two  cities.  Then  one  satellite  in  the  path  was  removed  by  setting  its  altitude  to  a 
negative  number.  The  simulation  was  run  again  to  ensure  that  the  packets  no  longer  used 
the  removed  satellite  in  its  path.  All  of  these  tests  gave  the  expected  results 
demonstrating  that  the  logic  of  the  model  is  sound. 

The  test  of  the  route  that  a  packet  took  through  the  network  revealed  that  the 
Satcom  Router  block  in  SATLAB  was  not  generating  a  routing  table  that  accurately 
modeled  the  IRIDIUM®  system.  The  routing  table  took  into  account  line-of-sight 
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visibility  between  satellites,  but  allowed  packets  to  be  routed  between  nonadjacent  orbital 
planes.  For  example,  a  packet  could  go  from  a  satellite  in  orbital  plane  one  to  a  satellite 
in  orbital  plane  three.  This  problem  was  brought  to  the  attention  of  two  of  the  developers 
of  SATLAB,  and  they  provided  C  code  for  a  new  routing  block  that  accurately  modeled 
the  inter-orbit  IRIDIUM®  links.  They  had  developed  this  code  for  research  they  were 
performing  in  the  area  of  antenna  pointing  angles  for  LEO  satellites  [Kel96].  This  code 
was  implemented  in  a  Designer  primitive  block,  and  the  new  routing  block  performed  as 
expected. 

3.7.2  Validation 

The  validation  of  the  model  consisted  of  comparing  the  end-to-end  delay  values 
generated  by  the  model  with  theoretical  values.  The  theoretical  values  were  calculated 
using  the  equations  in  Section  3.4.8.  Since  the  IRIDIUM®  network  is  not  yet  operational 
it  is  impossible  to  compare  the  model  outputs  with  actual  measured  data.  However,  the 
order  of  magnitude  of  the  delay  can  be  compared  to  real  time  communication 
requirement  of  400-ms.  Pilot  tests  of  the  simulation  were  conducted  with  a  low  loading 
level  and  a  full  satellite  constellation.  The  low  load  was  used  to  minimize  the  effects  of 
queuing  delay  since  this  is  difficult  to  calculate  using  the  equations  in  Section  3.4.8.  The 
number  of  satellites  in  the  path  was  determined  using  the  Hop  Count  field  of  the  received 
packet.  The  delay  values  output  by  the  simulation  were  consistent  with  the  calculated 
values  in  all  cases. 
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3.8  Algorithmic  Selection  of  Failed  Satellites 

The  intent  of  analyzing  the  IRIDIUM®  system  performance  with  a  degraded 
satellite  constellation  is  to  determine  how  many  satellites  can  fail  before  the  network 
performance  becomes  unacceptable.  Therefore,  it  is  desirable  to  determine  which 
satellites  are  most  important  with  regard  to  network  end-to-end  delay.  Before  developing 
an  algorithm  to  determine  the  critical  satellites,  it  is  necessary  to  examine  how  failed 
satellites  affect  end-to-end  delay.  This  makes  it  possible  to  define  the  scope  of  the 
algorithm. 

The  effect  of  a  failed  satellite  on  end-to-end  delay  varies  over  time  for  each  earth 
station.  At  some  times  the  satellite  is  not  in  the  path  from  the  earth  station  to  any  other 
earth  station.  At  these  times  the  failure  of  the  satellite  has  no  effect  on  the  end-to-end 
delay  of  packets  transmitted  from  the  earth  station.  The  satellite  is  in  the  shortest  path  to 
other  earth  stations  during  some  time  periods.  The  loss  of  the  satellite  at  these  times  will 
increase  the  end-to-end  delay  to  other  earth  stations  because  the  packets  must  take 
alternate  longer  paths.  Finally,  the  satellite  may  provide  the  only  uplink  for  the  earth 
station  for  a  certain  period  of  time.  During  this  time,  the  loss  of  the  satellite  will  prevent 
the  earth  station  from  transmitting.  It  is  clear  from  this  discussion  that  a  satellite's  failure 
effects  geographically  separated  earth  stations  differently  at  any  given  time. 

The  preceding  discussion  suggests  that  the  effect  of  failed  satellites  on  end-to-end 
delay  should  be  analyzed  for  a  single  transmitting  earth  station  and  for  a  limited  period  of 
time.  It  also  illustrates  that  the  removed  satellites  must  not  disconnect  the  earth  stations 
in  order  for  packets  to  travel  between  them.  Therefore,  the  decision  was  made  to  have 
the  algorithm  find  the  critical  satellites  for  packets  leaving  Kansas  City  during  a  ten- 
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minute  period  while  the  uplink  satellite  remained  the  same.  The  algorithm  would  also  be 
prevented  from  removing  the  uplink  satellite  or  any  other  satellite  that  disconnected  the 
network.  With  the  scope  of  the  algorithm  defined,  it  is  now  necessary  to  determine  how 
the  algorithm  will  select  critical  satellites. 

The  selection  of  critical  nodes,  as  discussed  in  Section  2.9,  can  be  based  either  on 
the  network  topology  or  on  the  loading  of  the  nodes.  Because  each  satellite  has  up  to 
four  ISLs,  it  is  not  possible  to  select  critical  satellites  based  only  upon  the  network 
topology.  So,  the  algorithm  to  select  critical  satellites  should  be  based  on  the  satellite 
loading  level.  One  measure  of  a  satellite's  loading  is  the  number  of  paths  it  is  in.  For 
example,  the  path  that  packets  take  from  Kansas  City  to  all  other  earth  stations  can  be 
determined.  The  removal  of  the  node  that  is  in  the  greatest  number  of  paths  will  affect 
the  end-to-end  delay  to  more  earth  stations  than  any  other  node.  As  such,  this  satellite  is 
the  most  critical  node.  Pilot  tests  were  conducted  to  test  the  effect  of  removing  these 
satellites  on  end-to-end  delay.  The  tests  indicated  that  up  to  seven  satellites  would  need 
to  be  removed  at  low  loading  levels  to  significantly  impact  end-to-end  delay.  This  led  to 
the  decision  to  have  the  algorithm  remove  three,  five  and  seven  satellites. 

The  discussion  in  this  section  provides  the  basis  for  the  development  of  the 
following  algorithm.  This  algorithm  is  used  to  select  the  critical  satellites  that  are 
removed  from  the  constellation: 

1 .  Generate  packets  and  determine  the  paths  from  Kansas  City  to  all  others. 

2.  Count  the  number  of  paths  that  each  satellite  is  in. 

3.  Remove  the  satellite  in  the  most  number  of  paths  that  does  not  disconnect  the 
network.  In  the  case  of  a  tie,  remove  the  satellite  closest  to  Kansas  City. 
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4.  Remove  the  satellite  in  the  second  most  number  of  paths  that  does  not  disconnect 
the  network  and  is  not  in  the  same  path  as  the  satellite  removed  in  step  3.  In  the  case 
of  a  tie,  remove  the  satellite  closest  to  Kansas  City. 

5.  Remove  the  satellite  in  the  third  most  number  of  paths  that  does  not  disconnect  the 
network  and  is  not  in  the  same  path  as  the  satellites  removed  in  steps  3  or  4.  In  the 
case  of  a  tie,  remove  the  satellite  closest  to  Kansas  City. 

6.  Repeat  steps  1  through  4  to  select  the  fourth  and  fifth  satellites. 

7.  Repeat  steps  1  through  4  to  select  the  sixth  and  seventh  satellites. 

3.9  Input  Parameters 

The  input  parameters  of  the  simulation  are  the  parameters  that  are  changed  to 
create  different  test  cases.  Each  of  these  parameters  has  been  previously  mentioned  in 
this  chapter.  They  are  defined  below  with  the  range  of  values  that  will  be  used. 

3.9.1  Loading  Level 

The  loading  level  is  defined  as  the  percent  utilization  of  the  earth  station  uplinks. 
This  parameter  is  adjusted  by  changing  the  mean  time  between  packet  arrivals.  The 
values  that  will  be  used  for  loading  level  are  50%,  83%  and  100%,  as  discussed  in 
Section  3.4.4. 

3.9.2  Number  of  Satellites  Removed 

This  parameter  is  the  defined  as  the  number  of  failed  satellites  in  the  constellation. 
The  failed  satellites  will  be  selected  using  the  algorithm  discussed  in  Section  3.8.  The 
values  that  will  be  used  for  number  of  satellites  removed  are  3, 5  and  7. 
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3.9.3  Traffic  Distribution 


The  traffic  distribution  is  defined  as  the  probability  that  a  packet  is  transmitted 
between  each  pair  of  nodes.  The  traffic  distributions  will  be  made  according  to  the  tables 
presented  in  Section  3.4.5.  These  tables  correspond  to  a  uniform  distribution,  a  non- 
uniform  distribution  at  low  load,  and  a  non-uniform  distribution  at  medium  load. 

3.10  Performance  Metrics 

3.10.1  End-to-End  Delay 

The  end-to-end  packet  delay  is  defined  as  the  mean  packet  delay  for  packets 
transmitted  from  Kansas  City  to  all  other  earth  stations.  The  model  calculates  the  delay 
for  each  packet  using  the  equations  in  Section  3.4.8.  This  is  the  primary  measure  of 
network  performance.  The  benchmark  for  end-to-end  packet  delay  is  400-ms,  and  a 
delay  higher  than  this  indicates  unacceptable  performance. 

3.10.2  Packet  Rejection  Rate 

The  packet  rejection  rate  is  defined  as  the  ratio  of  rejected  packets  to  transmitted 
packets.  Rejected  packets  are  defined  as  the  number  of  packets  that  leave  the  sending 
earth  station  but  do  not  reach  the  receiving  earth  station  due  to  the  overflow  of  queues  in 
the  network  model.  The  benchmark  for  packet  rejection  rate  is  1%,  and  a  rejection  rate 
higher  than  this  indicates  unacceptable  performance. 

3.10.3  Average  Number  of  Visible  Satellites 

The  average  number  of  visible  satellites  is  defined  as  the  mean  number  of 
satellites  visible  from  a  given  earth  station  over  a  24-hour  period.  The  mean  number  of 
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satellites  is  calculated  using  Equation  22  where  n  is  the  number  of  satellites  visible,  and 
p(n)  is  the  percentage  of  24-hours  that  n  satellites  are  visible. 

E(n)=  £ p(n)n  (22) 

x=0 

The  benchmark  for  average  number  of  visible  satellites  is  1.44,  which  is  the  mean  value 
for  all  scenarios  tested. 

3.10.4  Cumulative  Outage  Time 

Cumulative  Outage  Time  is  defined  as  the  total  number  of  minutes  that  an  earth 
station  is  unable  to  access  the  network  in  a  24-hour  period.  The  ability  to  access  the 
network  is  defined  in  Section  3.4.9.  The  IRIDIUM®  system  is  designed  so  that  a  user 
anywhere  in  the  world  will  have  continuous  access  to  the  network  through  at  least  one  of 
the  66  satellites.  As  a  result  of  the  non-operational  satellites  in  this  research,  there  will  be 
times  during  a  24-hour  period  when  a  user  will  have  no  satellite  available  to  access  the 
network.  This  is  very  different  from  a  traditional  terrestrial  network  due  to  the  dynamic 
nature  of  the  IRIDIUM®  network.  In  the  IRIDIUM®  network,  a  non-operational 
satellite  node  will  pass  overhead  and  within  approximately  ten  minutes  the  user  will  have 
network  access  through  another  satellite.  In  a  terrestrial  based  network,  a  non-operational 
node  will  deny  local  users  access  to  the  network  for  the  entire  24-hour  period.  The 
benchmark  for  Cumulative  Outage  Time  is  55.41 -minutes,  which  is  the  mean  value  for 
all  scenarios  tested. 
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3.10.5  Maximum  Continuous  Outage  Time 

Maximum  Continuous  Outage  Time  is  defined  as  the  maximum  continuous  time 
that  an  earth  station  is  unable  to  access  the  network  in  a  24-hour  period.  The  ability  to 
access  the  network  is  defined  in  Section  3.4.9.  As  discussed  in  Section  3.10.4,  the 
dynamic  nature  of  the  IRIDIUM®  system  makes  it  very  different  than  a  traditional 
terrestrial  system  when  nodes  become  non-operational.  In  a  terrestrial  network,  the 
failure  of  a  node  will  result  in  a  continuous  outage  time  of  24-hours  for  local  users.  In 
the  IRIDIUM®  network,  the  failure  of  several  satellite  nodes  will  result  in  a  continuous 
outage  time  less  than  30-minutes.  The  benchmark  for  Maximum  Continuous  Outage 
Time  is  12.04-minutes,  which  is  the  average  value  of  all  scenarios  tested. 

3.11  Summary 

This  chapter  has  presented  the  methodology  used  to  develop  the  simulation 
model.  The  development  of  a  simulation  model  required  that  the  scope  of  the  problem  be 
limited.  The  model  design  and  the  facts  and  assumptions  used  in  the  model  were 
explained.  Both  the  method  of  scaling  the  model  and  the  algorithm  for  selecting  critical 
satellites  were  developed.  The  process  used  to  validate  correct  operation  of  the 
simulation  model  was  explained.  Finally,  the  input  parameters  and  measured  outputs  of 
the  model  were  defined  and  explained. 
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CHAPTER  4 


ANALYSIS 


4.1  Introduction 

The  purpose  of  this  chapter  is  to  present  an  analysis  of  the  data  generated  with  the 
simulation.  The  chapter  begins  with  a  discussion  of  the  statistical  accuracy  of  the  data  in 
Section  4.2.  The  analysis  of  the  IRIDIUM®  system  was  conducted  in  two  parts.  First,  it 
was  assumed  that  the  user  could  access  the  network  despite  the  non-operational  satellites. 
Using  this  assumption,  an  analysis  was  made  of  both  the  end-to-end  delay  and  the  packet 
rejection  rates  from  Kansas  City  to  all  other  earth  stations.  This  is  covered  in  Sections 
4.3  through  4.5.  Section  4.3  defines  the  test  scenarios  that  were  used.  In  Section  4.4,  an 
analysis  of  the  end-to-end  delay  and  packet  rejection  for  all  test  scenarios  is  presented. 
An  analysis  of  each  test  scenario  is  presented  in  Section  4.5.  The  second  part  of  the 
analysis  focuses  on  an  earth  station’s  ability  to  access  the  network  as  satellites  fail.  This 
is  presented  in  Sections  4.6  through  4.8.  In  Section  4.6,  the  network  access  scenarios  are 
defined.  An  analysis  of  the  average  number  of  visible  satellites,  cumulative  outage  time, 
and  maximum  outage  time  for  all  scenarios  is  presented  in  Section  4.7.  Section  4.8 
provides  an  analysis  of  each  network  access  test  scenario.  Finally  an  overall  assessment 
of  the  IRIDIUM®  system  combining  both  approaches  is  made  in  Section  4.9. 

4.2  Statistical  Accuracy 

The  simulation  was  run  with  different  random  number  generator  seed  values  to 
ensure  that  the  end-to-end  delay  results  were  independent  of  a  specific  Poisson  traffic 
arrival  pattern.  Three  different  seed  values  were  used  for  each  combination  of  input 
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parameters  tested.  This  produced  three  sample  means  of  the  end-to-end  delay  between 
Kansas  City  and  each  other  earth  station.  The  95%  confidence  interval  of  the  mean  end- 
to-end  delay  was  calculated  using  the  student's  t-distribution  as  shown  in  Equation  23 

where  x  is  the  average  sample  mean,  s  is  the  standard  deviation  of  the  sample  means,  n 
is  the  number  of  sample  means,  and  t  is  the  student's  t-distribution  [Jai91]. 

100(l -a)%C/  =  x  ±t  [1  -a;n -l]s/yfn  (23) 

There  is  an  inherent  variance  in  the  end-to-end  delay  between  two  earth  stations  in  the 
IRIDIUM®  network.  This  variance  is  the  result  of  the  dynamically  changing  path,  and 
corresponding  changing  propagation  distance,  between  two  earth  stations  as  the  satellite 
constellation  moves.  Based  upon  this  inherent  variance,  a  confidence  interval  of  95% 
was  selected  to  express  the  statistical  accuracy  of  the  data.  A  95%  confidence  interval 
provides  high  confidence  that  the  variance  in  end-to-end  delay  is  within  a  range  that  is 
orders  of  magnitude  less  than  the  mean  end-to-end  delay  value.  The  95%  confidence 
interval  for  the  end-to-end  delay  from  Kansas  City  to  other  earth  stations  with  a  uniform 
traffic  distribution  and  low  loading  level  is  shown  in  Table  10.  The  95%  confidence 
interval  for  the  mean  end-to-end  delay  is  less  than  ±1.5-ms  for  each  earth  station  in  Table 
10.  This  shows  that  three  runs  of  the  simulation  with  different  seed  values  are  sufficient 
to  produce  a  small  confidence  interval  using  the  given  input  test  parameters.  It  is 
expected  that  the  variance  in  end-to-end  delay  will  be  greater  at  high  loading  levels  with 
several  non-operational  satellites.  The  95%  confidence  interval  for  the  end-to-end  delay 
from  Kansas  City  to  all  other  earth  stations  with  a  non-uniform  traffic  distribution, 
medium  loading  level,  and  seven  non-operational  satellites  is  shown  in  Table  11. 
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Table  10: 95%  Cl  for  Uniform-Low-Load  With  a  Full  Satellite  Constellation 


From 

Kansas  City 
to: 

Average 

Sample 

Mean 

Standard 

Deviation 

95%  Confidence  Interval  | 

Minimum 

Maximum 

Dhahran 

0.12600 

0.00005 

0.12588 

0.12613 

Melbourne 

0.13721 

0.00024 

0.13660 

0.13781 

urn— i 

0.11384 

0.00046 

0.11268 

0.11499 

EJiESSEB 

0.12842 

0.00049 

0.12721 

0.12964 

Rio 

0.09817 

0.00035 

0.09730 

0.09904 

Berlin 

0.12377 

0.00015 

0.12340 

0.12415 

Table  11: 95%  Cl  for  Non-uniform-Medium-Load  and  Seven  N on-operational  Satellites 


From 

Kansas  City 
to: 

Average 

Sample 

Mean 

Standard 

Deviation 

95%  Confidence  Interval  I 

Minimum 

Maximum 

Dhahran 

0.29957 

0.00384 

0.29002 

0.30911 

Melbourne 

mfzmm 

0.00391 

wassem 

0.23656 

onniiF— 

0.28026 

0.00309 

0.27259 

0.28794 

0.29050 

0.00718 

0.27267 

0.30834 

Rio 

0.00202 

0.25671 

0.26673 

Berlin 

0.21488 

0.00048 

0.21368 

0.21608 

The  95%  confidence  interval  is  less  than  ±  17-ms  for  each  earth  station  in  Table  11.  This 
shows  that  even  under  conditions  with  a  high  variance  in  mean  end-to-end  delay,  three 
runs  of  the  simulation  with  independent  seed  values  are  sufficient.  From  this  point  on, 
the  values  shown  for  mean  end-to-end  delay  represent  the  average  mean  end-to-end  delay 
as  depicted  in  Table  10  and  Table  11.  Similar  tables  with  the  confidence  intervals  for  all 
simulation  runs  are  given  in  the  Appendix. 

4.3  Delay  Test  Scenarios 

The  analysis  of  end-to-end  delay  and  packet  rejection  rate  was  conducted  using 
five  different  test  scenarios.  The  scenarios  represent  a  combination  of  the  simulation’s 
input  parameters  Loading  Level  and  Traffic  Distribution  as  defined  in  Sections  3.9.1  and 
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3.9.3  respectively.  Each  of  the  test  scenarios  was  run  with  zero,  three,  five,  and  seven 
non-operational  satellites.  The  non-operational  satellites  were  selected  according  to  the 
algorithm  presented  in  Section  3.8. 

4.3.1  Uniform  Distribution  Low  Load 

This  scenario  serves  as  a  baseline  for  comparison  with  the  other  defined 
scenarios.  It  represents  the  network  operating  with  little  strain  from  either  the  traffic 
distribution  or  the  loading  level.  It  uses  the  uniform  traffic  distribution  presented  in 
Table  4.  Each  of  the  seven  earth  stations  has  an  uplink  utilization  level  of  50%.  As 
shown  in  Table  3,  this  corresponds  to  a  network  arrival  rate  of  149,338  packets-per- 
second  with  each  of  the  seven  earth  stations  generating  21,334  packets-per-second.  Since 
this  scenario  uses  a  low  loading  level,  there  should  not  be  a  significant  amount  of  queuing 
delay  with  a  full  satellite  constellation. 

4.3.2  Uniform  Distribution  Medium  Load 

This  scenario  models  the  network  under  a  moderate  offered  load.  As  in  the 
previous  scenario,  it  uses  the  uniform  traffic  distribution  presented  in  Table  4.  The 
uplink  utilization  level  is  increased  to  83%  for  each  of  the  seven  earth  stations.  As  shown 
in  Table  3,  this  represents  a  network  arrival  rate  of  248,892  packets-per-second  with  each 
earth  station  generating  35,556  packets-per-second.  It  is  expected  that  the  end-to-end 
delay  with  a  full  satellite  constellation  will  increase  from  the  previous  scenario  due  to  the 
effects  of  queuing  delay. 

4.3.3  Uniform  Distribution  High  Load 

This  scenario  models  the  network  with  a  high  loading  level.  The  scenario  uses 
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the  uniform  traffic  distribution  presented  in  Table  4.  Each  of  the  earth  stations  transmits 
at  a  maximum  uplink  utilization  level  of  100%.  As  shown  in  Table  3,  this  represents  a 
network  arrival  rate  of  298,669  packets-per-second  with  each  earth  station  generating 
42,667  packets-per-second.  It  is  expected  that  queuing  delay  will  have  a  significant 
impact  on  the  end-to-end  delay  in  this  scenario. 

4.3.4  Non-uniform  Distribution  Low  Load 

This  scenario  models  the  network  with  two  earth  stations  transmitting  and 
receiving  most  of  the  traffic  and  a  low  network  offered  load.  It  uses  the  non-uniform 
traffic  distribution  presented  in  Table  5.  As  discussed  in  Section  3.4.5,  an  actual  network 
is  not  likely  to  have  a  uniform  traffic  distribution.  This  scenario  will  analyze  the  effect  of 
a  more  realistic  traffic  distribution  on  network  performance.  The  network  arrival  rate  is 
149,338  packets-per-second,  which  is  the  same  as  that  used  in  the  Uniform  Low  Load 
scenario  described  in  Section  4.3.1.  Since  the  traffic  is  not  uniformly  distributed  between 
the  earth  stations,  they  do  not  all  transmit  at  an  uplink  utilization  level  of  50%.  Kansas 
City  and  Dhahran  transmit  at  approximately  88%  uplink  utilization,  while  the  remaining 
earth  stations  transmit  at  approximately  35%  uplink  utilization. 

4.3.5  Non-Uniform  Distribution  Medium  Load 

This  scenario  models  the  network  with  two  earth  stations  transmitting  and 
receiving  most  of  the  traffic  and  a  moderate  network  offered  load.  It  uses  the  non- 
uniform  traffic  distribution  presented  in  Table  7.  As  discussed  in  Section  3.4.5,  an  actual 
network  is  not  likely  to  have  a  uniform  traffic  distribution.  This  scenario  will  analyze  the 
effect  of  a  more  realistic  traffic  distribution  on  network  performance.  The  network 
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arrival  rate  is  248,892  packets-per-second,  which  is  the  same  as  that  used  in  the  Uniform 
Medium  Load  scenario  described  in  Section  4.3.2.  Since  the  traffic  is  not  uniformly 
distributed  between  the  earth  stations,  they  do  not  all  transmit  at  an  uplink  utilization 
level  of  83%.  Kansas  City  and  Dhahran  transmit  at  approximately  94%  uplink 
utilization,  while  the  remaining  earth  stations  transmit  at  approximately  79%  uplink 
utilization. 

4.4  Analysis  of  Delay  Performance  Metrics 

The  primary  measurements  used  to  assess  the  IRIDIUM®  network's  ability  to 
provide  real-time  communications  were  the  mean  end-to-end  packet  delay  and  the  packet 
rejection  rate  as  defined  in  Sections  3.10.1  and  3.10.2.  The  simulation  was  designed  to 
operate  with  both  an  end-to-end  delay  less  than  400-ms  and  a  packet  rejection  rate  less 
than  1%  using  the  Uniform  High  Load  input  parameters  described  in  Section  4.3.3  and  a 
full  satellite  constellation.  Both  the  maximum  end-to-end  delay  and  the  packet  rejection 
rate  are  dependent  upon  the  maximum  queue  size  defined  in  Section  3.4.10.  Increasing 
the  queue  size  will  reduce  the  packet  rejection  rate  at  the  expense  of  increased  end-to-end 
delay.  Likewise,  decreasing  the  queue  size  will  reduce  the  end-to-end  delay  at  the 
expense  of  increased  packet  rejections.  Both  of  these  parameters  must  be  taken  into 
consideration  when  assessing  the  network  performance. 

4.4.1  Delay  Analysis 

The  mean  end-to-end  packet  delay  measured  from  Kansas  City  to  all  other  earth 
stations  was  below  400-ms  for  all  test  scenarios.  The  lowest  mean  end-to-end  delay  was 
98.17-ms  between  Kansas  City  and  Rio  de  Janeiro  in  the  Uniform  Low  Load  scenario 
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with  a  full  satellite  constellation.  The  highest  mean  end-to-end  delay  was  290.021 -ms 
between  Kansas  City  and  Dhahran  in  the  Non-uniform  Medium  Load  scenario  with  seven 
non-operational  satellites.  The  fact  that  no  scenarios  had  a  mean  end-to-end  packet  delay 
above  400-ms  was  expected  based  upon  the  selection  of  queue  sizes  presented  in  3.4.10. 
The  queue  size  was  selected  so  those  individual  packets  with  an  end-to-end  delay  in 
excess  of  400-ms  would  be  rejected  from  the  network.  A  detailed  examination  of  the 
data  showed  that  a  small  number  of  packets  took  approximately  380-ms  to  390-ms  to 
reach  their  destination.  With  only  a  small  number  of  packets  approaching  400-ms  end-to- 
end  delay,  an  average  end-to-end  delay  of  290-ms  is  reasonable. 

The  end-to-end  delay  performance  had  several  trends  that  illustrated  the  effect  of 
varying  the  different  input  parameters.  The  first  was  that  increasing  the  loading  level  for 
a  given  traffic  distribution  with  a  full  satellite  constellation  had  a  significant  impact  on 
queuing  delay.  This  is  illustrated  for  a  uniform  traffic  distribution  with  a  full  satellite 
constellation  in  Figure  10. 


Delay  vs.  Uplink  Load  From  Kansas  City 

Full  Satellite  Constellation 
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Figure  10:  Delay  for  Uniform  Distribution  and  Full  Constellation 
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For  most  of  the  cities  in  Figure  10,  there  was  a  much  larger  increase  in  end-to-end  delay 
when  the  uplink  utilization  was  increased  form  83%  to  100%  then  when  it  was  increased 
from  50%  to  83%.  This  indicates  that  the  effects  of  queuing  delay  with  a  full  satellite 
constellation  are  most  significant  above  83%  uplink  utilization. 

The  second  trend  was  that  non-operational  satellites  had  a  significant  impact  on 
both  queuing  delay  and  end-to-end  delay.  Figure  11  plots  the  same  uniform  traffic 
distribution  and  uplink  utilization  as  Figure  10,  but  has  seven  non-operational  satellites. 


Delay  vs.  Uplink  Load  From  Kansas  City 

Seven  Non-operational  Satellites 
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Figure  11:  Delay  for  Uniform  Distribution  and  Seven  Non-operational  Satellites 


Most  of  the  cities  in  Figure  11  experienced  a  significant  increase  in  end-to-end  delay 


when  the  uplink  loading  is  increased  from  50%  to  83%.  The  delay  either  leveled  off  or 
decreased  when  the  utilization  was  increased  from  83%  to  100%.  This  indicates  that  the 


seven  non-operational  satellites  significantly  increased  the  queuing  delay  in  the  network 
between  the  low  loading  level  of  50%  uplink  utilization  and  the  moderate  level  of  83% 
uplink  utilization.  The  leveling  off  or  decrease  between  the  83%  and  100%  uplink 
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utilization  levels  was  a  result  of  increased  packet  rejections.  Those  packets  with  end-to- 
end  delays  above  400-ms  were  rejected  which  resulted  in  a  decrease  of  the  mean  end-to- 
end  delay  of  all  packets  successfully  transmitted  between  the  cities. 

A  third  trend  was  that  the  non-uniform  traffic  scenarios  had  higher  end-to-end 
delay  than  the  uniform  traffic  scenarios  with  the  same  network  arrival  rate.  The  traffic 
distributions  used  in  the  Non-uniform  Low  Load  and  the  Non-uniform  Medium  Load 
scenarios  both  had  a  high  traffic  link  between  Kansas  City  and  Dhahran.  As  discussed  in 
Section  4.3.4,  the  Non-uniform  Low  Load  and  Uniform  Low  Load  scenarios  had  the  same 
network  arrival  rate.  Similarly,  the  Non-uniform  Medium  Load  and  Uniform  Medium 
Load  scenarios  used  the  same  network  arrival  rate.  The  end-to-end  delay  between 
Kansas  City  and  Dhahran  is  plotted  against  the  number  of  non-operational  satellites  for 
each  of  the  test  scenarios  in  Figure  12. 


Figure  12  illustrates  that  the  non-uniform  traffic  distribution  increased  the  end-to-end 
delay  at  both  the  low  and  medium  loading  levels.  The  Non-uniform  Low  Load  scenario 
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had  a  higher  end-to-end  delay  than  the  Uniform  Low  Load  scenario,  while  the  Non- 
uniform  Medium  Load  scenario  had  a  higher  end-to-end  delay  than  the  Uniform  Medium 
Load  scenario.  This  result  held  true  not  only  for  the  high  traffic  link  of  Kansas  City  to 
Dhahran,  but  for  other  earth  stations  as  well.  The  end-to-end  delay  between  Kansas  City 
and  Berlin  is  plotted  against  the  number  of  non-operational  satellites  for  all  scenarios  in 
Figure  13. 


Figure  13  illustrates  that  the  non-uniform  traffic  distribution  had  the  same  effect  on  end- 
to-end  delay  from  Kansas  City  to  Berlin  that  it  had  on  that  from  Kansas  City  to  Dhahran. 
The  Non-uniform  Low  Load  scenario  had  a  higher  end-to-end  delay  than  the  Uniform 
Low  Load  scenario,  while  the  Non-uniform  Medium  Load  scenario  had  a  higher  end-to- 
end  delay  than  the  Uniform  Medium  Load  scenario. 


4.4.2  Packet  Rejection  Analysis 

The  packet  rejection  rate  varied  between  0%  and  8.98%  across  all  of  the  test 
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scenarios.  The  low  load  scenarios  had  the  best  performance  with  respect  to  packet 
rejection.  Both  the  Uniform  Low  Load  and  the  Non-uniform  Low  Load  scenarios  had  no 
packet  rejections  with  up  to  seven  non-operational  satellites.  The  Non-uniform  Medium 
Load  scenario  had  the  worst  packet  rejection  rate  of  8.98%  and  was  also  the  only  scenario 
that  rejected  packets  with  a  full  satellite  constellation.  The  packet  rejection  rate  is  plotted 
against  the  number  of  non-operational  satellites  for  all  scenarios  in  Figure  14. 


Figure  14:  Packet  Rejection  Rate  for  Each  Scenario 
Figure  14  illustrates  that  the  packet  rejection  rate  increased  with  both  the  loading  level 
and  the  number  of  non-operational  satellites.  Since  the  end-to-end  delay  was  below  the 
benchmark  of  400-ms  for  all  scenarios,  the  packet  rejection  rate  was  the  performance 
metric  that  determined  acceptable  performance.  The  benchmark  for  packet  rejection  was 
defined  as  1%  in  Section  3.10.2.  Figure  14  shows  several  trends  in  the  packet  rejection 
rate.  First,  with  a  full  satellite  constellation,  the  distribution  of  traffic  had  a  more 
significant  impact  on  network  performance  than  the  loading  level.  The  Non-uniform 
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Medium  Load  scenario  had  a  packet  rejection  rate  of  3.1 8%  while  the  Uniform  High  Load 
scenario  had  no  packet  rejections.  Next,  at  a  low  loading  level  the  system  performed  well 
despite  the  failure  of  satellites  or  the  distribution  of  traffic.  Both  the  Uniform  Low  Load 
and  the  Non-uniform  Low  Load  scenarios  had  no  packet  rejections  with  up  to  seven  non- 
operational  satellites.  This  illustrates  the  importance  of  evaluating  the  network  at  high 
loading  levels,  and  supports  the  results  previously  obtained  by  Stenger  [Ste96].  At  a 
medium  loading  level,  the  traffic  distribution  impacted  the  network  performance  more 
than  the  failure  of  satellites.  The  Uniform  Medium  Load  scenario  had  an  acceptable 
packet  rejection  rate  with  up  to  five  non-operational  satellites,  while  the  Non-uniform 
Medium  Load  scenario  performed  unacceptably  with  a  full  satellite  constellation. 
Finally,  at  a  high  loading  level  the  system  was  much  more  sensitive  to  the  failure  of 
satellites.  The  Uniform  High  Load  scenario  had  a  packet  rejection  rate  of  1.18%  with 
three  non-operational  satellites,  while  the  Uniform  Medium  Load  had  a  rejection  rate  of 
2.34%  with  seven  non-operational  satellites. 

4.5  Analysis  of  Delay  Test  Scenarios 

The  five  test  scenarios  described  in  Section  4.3  represent  different  operating 
conditions  for  the  IRIDIUM®  network.  The  effect  of  non-operational  satellites  on  both 
end-to-end  delay  and  packet  rejection  rate  was  analyzed  for  each  scenario.  For  each 
scenario  the  end-to-end  delay  was  measured  from  Kansas  City  to  the  six  other  earth 
stations.  The  percent  of  packets  generated  that  were  rejected  from  the  network  was  also 
calculated  for  each  scenario.  Both  of  these  measurements  were  made  with  zero,  three, 
five,  and  seven  non-operational  satellites. 
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4.5.1  Uniform  Distribution  Low  Load 


The  Uniform  Low  Load  scenario  had  end-to-end  delays  below  the  benchmark  of 
400-ms  and  no  packet  rejections  with  up  to  seven  non-operational  satellites.  With  a  full 
satellite  constellation,  the  end-to-end  delay  to  the  various  earth  stations  varied  from 
98.17-ms  to  137.21-ms.  With  seven  non-operational  satellites,  the  delay  varied  between 
160.95-ms  and  198.74-ms.  The  end-to-end  delay  is  plotted  against  the  number  of  non- 
operational  satellites  for  each  earth  station  in  Figure  15. 


Delay  from  Kansas  City  Uniform  Low  Load 
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Figure  15:  Delay  Kansas  City  to  Other  Earth  Stations  Uniform  Low  Load  Scenario 
Three  of  the  cities  in  Figure  15  experienced  an  increase  in  end-to-end  delay  with  three 
non-operational  satellites.  The  other  three  cities  did  not  have  a  significant  increase  in 
end-to-end  delay  until  either  five  or  seven  satellites  were  non-operational.  This  indicates 
that  the  increase  in  end-to-end  delay  resulted  primarily  from  the  change  in  path.  Queuing 
delay  did  not  have  a  significant  impact  at  this  loading  level.  In  this  scenario  the 
IRIDIUM®  system  was  able  to  provide  real-time  communications  despite  the  non- 
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operational  satellites.  The  performance  in  this  scenario  will  be  compared  with  the  other 
scenarios  to  determine  the  effect  of  increasing  the  traffic  load  or  changing  the  traffic 
distribution. 


4.5.2  Uniform  Distribution  Medium  Load 


The  Uniform  Medium  Load  Scenario  had  end-to-end  delays  below  the  benchmark 
of  400-ms  with  up  to  seven  non-operational  satellites  and  packet  rejection  rates  below  the 
benchmark  of  1%  with  up  to  five  non-operational  satellites.  With  a  full  satellite 
constellation,  the  end-to-end  delay  varied  between  109.36-ms  and  152.73-ms.  This  is  an 
increase  of  up  to  15.52-ms  over  the  maximum  delay  in  the  Uniform  Low  Load  Scenario 
with  a  full  satellite  constellation.  With  seven  non-operational  satellites  the  end-to-end 
delay  ranged  from  213.03-ms  to  279.97-ms.  This  is  an  increase  of  up  to  81.23-ms  above 
the  maximum  delay  in  the  Uniform  Low  Load  scenario  with  seven  non-operational 
satellites.  The  end-to-end  delay  is  plotted  against  the  number  of  non-operational 
satellites  for  each  earth  station  in  Figure  16. 


Delay  from  Kansas  City  Uniform  Medium  Load 
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Figure  16:  Delay  from  Kansas  City  to  Other  Earth  Stations  Uniform  Medium  Load 
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All  six  of  the  cities  in  Figure  16  experienced  an  increase  in  end-to-end  delay  with  three 
non-operational  satellites.  The  delay  increased  for  each  earth  station,  as  more  satellites 
become  non-operational.  This  indicates  that  queuing  delay  had  a  significant  role  and  that 
the  increase  in  delay  was  not  simply  the  result  of  a  changing  path.  There  were  no  packet 
rejections  with  zero  or  three  non-operational  satellites.  The  packet  rejection  rate  was 
0.03%  with  five  non-operational  satellites  and  2.34%  with  seven  non-operational 
satellites.  In  this  scenario  the  IRIDIUM®  system  was  able  to  provide  real-time 
communications  with  up  to  five  non-operational  satellites. 

4.5.3  Uniform  Distribution  High  Load 

The  Uniform  High  Load  scenario  had  end-to-end  delays  below  the  benchmark  of 
400-ms  with  up  to  seven  non-operational  satellites  and  packet  rejection  rates  below  the 
benchmark  of  1%  with  a  full  satellite  constellation.  The  end-to-end  delay  ranged  from 
124.19-ms  to  211.53-ms  with  a  full  satellite  constellation.  This  is  an  increase  of  up  to 
74.32-ms  over  the  maximum  delay  for  the  Uniform  Low  Load  scenario  with  a  full 
satelliteconstelation.  The  end-to-end  delay  varied  between  229.76-ms  and  28 1.01 -ms 
with  seven  non-operational  satellites.  This  is  an  increase  of  up  to  82.27-ms  over  the 
Uniform  Low  Load  scenario  with  seven  non-operational  satellites.  The  end-to-end  delay 
is  plotted  against  the  number  of  non-operational  satellites  for  all  earth  stations  in  Figure 
17.  Most  of  the  cities  in  Figure  17  experienced  an  increase  in  end-to-end  delay  with  three 
non-operational  satellites.  However,  the  delay  leveled  off  for  three  of  the  cities  with  five 
and  seven  non-operational  satellites.  This  indicates  that  the  network  was  experiencing 
packet  rejections. 
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Figure  17:  Delay  from  Kansas  City  to  Other  Earth  Stations  Uniform  High  Load 
The  packets  between  Kansas  City  and  these  cities  that  had  delays  in  excess  of  400-ms 
were  being  rejected  and  the  mean  end-to-end  packet  delay  did  not  increase.  The  packet 
rejection  rate  with  three  non-operational  satellites  was  1.18%  and  it  increased  to  5.34% 
with  seven  non-operational  satellites.  In  this  scenario,  the  IRIDIUM®  system  is  only 
able  to  provide  real-time  communications  with  a  full  satellite  constellation. 

4.5.4  Non-uniform  Distribution  Low  Load 

The  Non-uniform  Low  Load  scenario  had  end-to-end  delays  below  the  benchmark 
of  400-ms  and  no  packet  rejections  with  up  to  seven  non-operational  satellites.  The  end- 
to-end  delay  ranged  from  1 1 1.36-ms  to  151.46-ms  with  a  full  satellite  constellation.  This 
is  an  increase  of  up  to  14.25-ms  over  the  maximum  delay  for  the  Uniform  Low  Load 
scenario  with  a  full  satellite  constellation.  The  end-to-end  delay  varied  between  202.68- 
ms  and  260.65-ms  with  seven  non-operational  satellites.  This  is  an  increase  of  up  to 
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61.91-ms  over  the  Uniform  Low  Load  scenario  with  seven  non-operational  satellites. 


The  end-to-end  delay  is  plotted  against  the  number  of  non-operational  satellites  for  all 


earth  stations  in  Figure  18. 
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Figure  18:  Delay  from  Kansas  City  to  Other  Earth  Stations  Non-uniform  Low  Load 
Each  of  the  cities  in  Figure  18  experienced  an  increase  in  end-to-end  delay  with  three 


non-operational  satellites.  This  indicates  that  queuing  delay  is  affecting  the  end-to-end 


delay  for  all  cities.  Despite  the  fact  that  this  scenario  had  a  high  volume  of  traffic 
between  Kansas  City  and  Dhahran,  the  end-to-end  delay  to  Dhahran  was  not  the  highest 
of  all  the  cities.  This  was  due  to  the  fact  that  the  network  was  operating  at  a  low  loading 
level.  In  this  scenario  the  IRIDIUM®  system  was  able  to  provide  real-time 


communications  with  up  to  seven  non-operational  satellites. 


4.5.5  Non-Uniform  Distribution  Medium  Load 


The  Non-uniform  Medium  Load  scenario  had  end-to-end  delays  below  the 
benchmark  of  400-ms  with  up  to  seven  non-operational  satellites,  but  was  the  only 
scenario  that  rejected  packets  with  a  full  satellite  constellation.  The  end-to-end  delay 
ranged  from  134.13-ms  to  207.12-ms  with  a  full  satellite  constellation.  This  is  an 
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increase  of  up  to  69.91 -ms  over  the  maximum  delay  for  the  Uniform  Low  Load  scenario 
with  a  full  satellite  constellation.  The  end-to-end  delay  varied  between  214.88-ms  and 
299.57-ms  with  seven  non-operational  satellites.  This  is  an  increase  of  up  to  100.83-ms 
over  the  Uniform  Low  Load  scenario  with  seven  non-operational  satellites.  The  end-to- 
end  delay  for  each  of  the  earth  stations  is  plotted  against  the  number  of  non-operational 
satellites  in  Figure  19. 
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Figure  19:  Delay  from  Kansas  City  to  Other  Earth  Stations  Non-uniform  Medium  Load 
The  end-to-end  delay  for  most  of  the  cities  in  Figure  19  increased  as  the  number  of  non- 
operational  satellites  increased.  The  end-to-end  delay  between  Kansas  City  and  Dhahran 
was  higher  than  that  between  Kansas  City  and  any  other  earth  station  with  three  to  seven 
non-operational  satellites.  At  this  loading  level,  the  high  traffic  link  between  Kansas  City 
and  Dhahran  experienced  significant  queuing  delay.  The  packet  rejection  rates  in  this 
scenario  ranged  from  3.18%  with  a  full  satellite  constellation  to  8.98%  with  seven  non- 
operational  satellites.  As  a  result  of  both  the  non-uniform  traffic  distribution  and  medium 
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traffic  load,  this  scenario  was  not  able  to  meet  the  real-time  voice  traffic  benchmark  of 
1%  packet  rejection. 

4.6  Network  Access  Test  Scenarios 

The  analysis  of  an  earth  station's  ability  to  access  the  IRIDIUM®  network  was 
conducted  with  two  different  scenarios.  The  scenarios  represent  different  earth  stations 
since  the  average  number  of  satellites  visible  changes  with  the  latitude  of  the  earth 
station.  Each  of  the  test  scenarios  was  run  with  zero,  three,  five,  and  seven  non- 
operational  satellites.  The  access  tests  used  the  same  non-operational  satellites  as  the 
delay  tests.  Up  to  this  point  in  the  chapter,  the  analysis  has  focused  on  the  effect  of  non- 
operational  satellites  on  end-to-end  delay  and  packet  rejection  rate  under  the  assumption 
that  the  earth  station  could  access  the  network.  Now,  the  focus  shifts  to  an  earth  station's 
ability  to  access  the  network  over  a  period  of  24-hours.  The  period  of  24-hours  was 
selected  because  the  earth  stations  and  the  satellite  constellation  are  in  the  same  relative 
position  approximately  every  24-hours.  An  earth  station  sees  each  IRIDIUM®  satellite 
twice  each  day.  One  time  it  will  be  travelling  from  North  to  South,  and  the  other  time 
from  South  to  North. 

4.6.1  Equatorial  City 

The  Equatorial  City  scenario  models  the  visibility  of  satellites  over  time  from  a 
location  directly  on  the  equator.  Since  the  IRIDIUM®  orbits  are  near-polar,  the  distance 
between  satellites  in  adjacent  orbital  planes  is  the  largest  when  they  are  over  the 
equatorial  region.  The  larger  separation  between  satellites  causes  the  earth  stations  at  the 
equator  to  have  fewer  visible  satellites.  In  this  respect  the  Equatorial  City  scenario 
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serves  as  a  baseline  in  the  visibility  analysis.  The  failure  of  satellites  will  have  a  greater 
effect  on  an  equatorial  city  than  on  a  city  located  at  higher  or  lower  latitudes. 

4.6.2  North  American  City 

The  North  American  City  scenario  models  the  visibility  of  satellites  over  time 
from  Kansas  City.  This  provides  a  visibility  analysis  for  a  typical  city  in  the  Northern 
Hemisphere.  Because  of  the  symmetric  nature  of  the  IRIDIUM®  satellite  constellation, 
the  results  of  this  scenario  can  also  provide  a  visibility  analysis  for  a  typical  city  in  the 
Southern  Hemisphere. 

4.7  Analysis  of  Network  Access  Performance  Metrics 

The  performance  metrics  used  to  analyze  the  network  access  in  each  scenario 
were  the  average  number  of  visible  satellites,  the  cumulative  outage  time,  and  the 
maximum  outage  time  as  defined  in  Sections  3.10.3, 3.10.4,  and  3.10.5  respectively. 

4.7.1  Analysis  of  Average  Number  of  Visible  Satellites 

The  average  number  of  satellites  visible  over  a  24-hour  period  ranged  from  1.15 
to  1.69.  The  Equatorial  City  scenario  with  seven  non-operational  satellites  had  the 
lowest  average  visibility,  and  the  North  American  City  with  a  full  satellite  constellation 
had  the  highest  average  visibility.  The  average  number  of  visible  satellites  for  each 
scenario  is  plotted  against  the  number  of  non-operational  satellites  in  Figure  20.  Figure 
20  shows  that  in  both  scenarios  the  average  number  of  visible  satellites  decreased  at 
approximately  the  same  rate  when  the  number  of  non-operational  satellites  was  increased. 
It  also  shows  that  the  North  American  City  had  a  higher  average  number  of  visible 
satellites  with  seven  non-operational  satellites  than  the  Equatorial  City  had  with  a  full 
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satellite  constellation.  This  illustrates  that  a  user's  location  has  a  more  significant  impact 
on  his  ability  to  access  the  network  than  does  the  failure  of  satellites. 


Figure  20:  Average  Number  of  Visible  Satellites  by  Scenario 


4.7.2  Analysis  of  Cumulative  Outage  Time 

The  cumulative  outage  time  over  a  24-hour  period  ranged  from  a  low  of  zero 
minutes  to  a  high  of  120-minutes  across  all  test  scenarios.  As  discussed  in  Section 
3.10.4,  the  IRIDIUM®  system  is  designed  to  have  continuous  whole  earth  coverage. 
Both  the  Equatorial  City  scenario  and  the  North  American  City  scenario  had  no  outage 
time  with  a  full  satellite  constellation.  The  Equatorial  City  scenario  with  seven  non- 
operational  satellites  had  the  longest  cumulative  outage  of  120-minutes  in  a  24-hour 
period.  The  cumulative  outage  time  as  a  function  of  the  number  of  non-operational 
satellites  is  plotted  in  Figure  21.  The  North  American  City  experienced  significantly 
lower  cumulative  outage  times  because  it  had  a  larger  average  number  of  visible 
satellites.  The  Equatorial  City  experienced  cumulative  outage  times  longer  than  the 
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North  American  City  by  17-minutes  and  40-minutes  with  three  and  seven  non-operational 
satellites  respectively. 


Cumulative  Outage  Time  Over  24  Hours 
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Figure  21:  Cumulative  Outage  Time  by  Scenario 
The  Equatorial  City  slightly  exceeded  the  benchmark  of  55.41 -minutes  cumulative 
outage  time  with  three  non-operational  satellites.  The  North  American  City  exceeded  the 
same  benchmark  with  five  non-operational  satellites. 

4.7.3  Analysis  of  Maximum  Continuous  Outage  Time 
The  maximum  continuous  outage  time  over  a  24-hour  period  ranged  from  a  low 
of  zero  minutes  to  a  high  of  25.43-minutes.  As  discussed  in  Section  3.10.4,  the 
IRIDIUM®  system  is  designed  to  have  continuous  whole  earth  coverage.  Both  the 
Equatorial  City  and  the  North  American  City  scenarios  had  no  outages  with  a  full  satellite 
constellation.  The  Equatorial  City  scenario  with  seven  non-operational  satellites  had  the 
longest  outage  time  of  25.43-minutes.  The  maximum  outage  time  for  each  scenario  is 
plotted  as  a  function  of  non-operational  satellites  in  Figure  22. 
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Figure  22:  Maximum  Continuous  Outage  Time  by  Scenario 
The  North  American  City  and  the  Equatorial  City  experienced  similar  maximum  outage 
times  for  each  number  of  non-operational  satellites.  This  indicates  that  the  number  of 
non-operational  satellites  has  a  more  significant  impact  on  the  maximum  outage  time 
than  the  earth  station  location  does.  Both  the  North  American  City  and  the  Equatorial 
City  exceeded  the  benchmark  of  12.04-minutes  with  5  non-operational  satellites. 


4.8  Analysis  of  Network  Access  Test  Scenarios 

The  scenarios  defined  in  Section  4.6  have  different  abilities  to  access  the 
IRIDIUM®  network  based  upon  the  earth  station  geographical  location.  For  each 
scenario,  the  average  number  of  satellites,  cumulative  outage  time,  and  maximum  outage 
time  were  analyzed.  The  measurements  were  made  for  zero,  three,  five,  and  seven 
satellites  in  each  case. 
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4.8.1  Equatorial  City 

The  Equatorial  City  scenario  had  between  one  and  three  satellites  visible  with  a 
full  satellite  constellation.  The  percent  of  time  that  each  number  of  satellites  was  visible 
over  a  24-hour  period  is  plotted  in  Figure  23. 
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Figure  23:  Percent  of  Time  Satellites  Are  Visible  from  Equator 
The  Equatorial  City  had  one  visible  satellite  over  68%  of  the  time  and  two  visible 
satellites  less  than  28%  of  the  time  regardless  of  the  number  of  non-operational  satellites. 
Three  satellites  were  visible  less  than  0.05%  of  the  time.  The  network  access  results  for 
this  scenario  are  given  in  Table  12. 
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Table  12:  Network  Access  Results  for  Equatorial  City  Scenario 


Equator 

Number  o 

Non-operational  Sa 

tellites 

3 

5 

7 

Average  Number  of  Satellites  Visible 

1.28 

1.22 

1.18 

1.15 

Cumulative  Outage  Time  (min.) 

0.00 

55.43 

92.83 

120.00 

Maximum  Continuous  Outage  Time  (min) 

0.00 

8.04 

16.30 

25.43 
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The  results  in  Table  12  show  that  this  scenario  was  able  to  meet  the  maximum  continuous 


outage  time  benchmark  of  12.04-minutes  with  up  to  3  non-operational  The  Equatorial 
City  scenario  exceeded  .the  cumulative  outage  time  benchmark  of  55.41 -minutes  with 
only  three  non-operational  satellites. 

4.8.2  North  American  City 

The  North  American  City  had  from  1  to  4  satellites  visible  with  a  full  satellite 
constellation.  The  percent  of  time  that  each  number  of  satellites  was  visible  is  shown  in 
Figure  24. 
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Figure  24:  Percent  of  Time  Satellites  are  Visible  From  Kansas  City 
The  North  American  scenario  had  one  satellite  visible  over  40%  of  the  time  and 
two  satellites  visible  over  40%  of  the  time  regardless  of  the  number  of  non-operational 
satellites.  The  network  access  results  for  this  scenario  are  given  in  Table  13. 
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Table  1 3:  Network  Access  Results  for  North  American  City  Scenario 


Kansas  City 

Number  of  Non-operational  Sa 

tellltes 

3 

5 

7 

Average  Number  of  Scfellites  Visible 

1.69 

1.61 

1.56 

1.51 

Cumulctive  Outage  T 1  me  (min.) 

0.00 

36.96 

59.78 

78.26 

Macimum  Continuous  Outqge T  ime  (min) 

0.00 

7.17 

16.09 

23.26 

This  scenario  was  able  to  meet  both  the  cumulative  outage  time  benchmark  of  55.14- 
minutes  and  the  maximum  continuous  outage  time  benchmark  of  12.04-minutes  with  up 
to  3  non-operational  satellites. 

4.9  Summary  of  Analysis 

Both  the  delay  analysis  presented  in  Sections  4.3  to  4.5  and  the  network  access 
analysis  presented  in  Sections  4.6  to  4.8  demonstrated  that  the  IRIDIUM®  system  is  able 
to  meet  real-time  communications  constraints  with  a  number  of  non-operational  satellites. 
In  the  delay  analysis,  both  the  loading  level  and  the  traffic  distribution  had  a  significant 
impact  on  the  system's  ability  to  perform  with  non-operational  satellites.  The  Non- 
uniform  Medium  Load  scenario  had  a  packet  rejection  rate  of  3.18%  with  a  full 
constellation.  The  scenario  also  had  the  highest  rejection  rate  of  8.98%  with  seven  non- 
operational  satellites.  The  Uniform  High  Load  Scenario  was  the  next  most  sensitive  to 
satellite  failures  with  a  packet  rejection  rate  of  1.18%  for  three  non-operational  satellites. 
The  delay  analysis  demonstrated  the  importance  of  analyzing  the  IRIDIUM®  system  at 
high  loading  levels  and  non-uniform  traffic  distributions.  Since  only  one  non-uniform 
traffic  distribution  was  used  in  this  research,  future  research  in  this  area  could  examine 
other  traffic  distributions.  The  network  access  analysis  demonstrated  that  non- 
operational  satellites  have  a  significant  impact  on  a  user's  ability  to  access  the  network. 
The  delay  analysis  showed  that  the  IRIDIUM®  system  met  real-time  communications 


85 


constraints  at  low  loading  levels  with  up  to  seven  non-operational  satellites.  However, 
the  network  access  analysis  revealed  that  a  user's  ability  to  access  the  network  is 
significantly  degraded  with  three  to  five  non-operational  satellites.  This  illustrated  the 
importance  of  analyzing  both  the  delay  and  the  network  access  as  the  number  of  non- 
operational  satellites  increases. 
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CHAPTER  5 


CONCLUSIONS  AND  RECOMMENDATIONS 

5.1  Restatement  of  Research  Goal 

The  goal  of  this  research  was  to  assess  the  IRIDIUM®  Low  Earth  Orbit  (LEO) 
satellite  network's  capability  to  provide  real-time  communications  with  a  degraded 
satellite  constellation. 

5.2  Conclusions 

The  IRIDIUM®  LEO  satellite  network  is  a  robust  network  that  is  capable  of 
providing  real-time  voice  communications  with  multiple  non-operational  satellites.  The 
ability  of  the  system  to  meet  the  end-to-end  delay  benchmark  of  400-ms  and  packet 
rejection  rate  benchmark  of  1%  depends  upon  both  the  loading  level  and  traffic 
distribution.  With  a  low  loading  level,  the  IRIDIUM®  network  met  both  benchmarks 
with  seven  non-operational  satellites  regardless  of  the  traffic  distribution.  For  a  medium 
loading  level,  the  system  met  both  benchmarks  with  five  non-operational  satellites  and  a 
uniform  traffic  distribution.  A  medium  loading  level  with  a  non-uniform  traffic 
distribution  exceeded  the  packet  rejection  rate  benchmark  with  a  full  satellite 
constellation.  A  high  loading  level  with  a  uniform  traffic  distribution  exceeded  the 
packet  rejection  rate  benchmark  with  three  non-operational  satellites. 

The  ability  of  the  IRIDIUM®  network  to  meet  the  network  access  benchmarks  of 
cumulative  outage  time  less  than  55.41 -minutes  and  maximum  continuous  outage  time 
less  than  12.04-minutes  was  dependent  upon  the  earth  stations  location.  An  earth  station 
at  the  equator  met  the  maximum  continuous  outage  time  benchmark  with  three  non- 
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operational  satellites.  However,  the  scenario  only  met  the  cumulative  outage  time 
benchmark  with  a  full  satellite  constellation.  A  typical  North  American  city  met  both 
benchmarks  with  three  non-operational  satellites. 

The  robustness  of  the  IRIDIUM®  network  was  demonstrated  by  selecting  critical 
satellites  to  fail.  The  non-operational  satellites  were  selected  in  each  scenario  by 
algorithmically  determining  the  most  heavily  utilized  satellites.  From  this  respect,  the 
results  represent  a  worst  case  scenario.  The  results  of  a  similar  delay  analysis  and 
network  access  analysis  with  randomly  failing  satellites  should  result  in  better  network 
performance. 

5.3  Significant  Results  of  Research 

There  is  currently  a  lack  of  openly  published  literature  in  the  area  of  LEO  satellite 
network  survivability.  The  most  recent  work  by  Stenger  demonstrated  that  IRIDIUM® 
was  a  robust  network,  but  was  limited  to  an  analysis  at  low  loading  levels  due  to  long 
simulation  run  times  [Ste96].  One  of  the  most  significant  contributions  of  this  research 
was  the  analysis  of  the  IRIDIUM®  network  at  high  loading  levels.  By  appropriately 
scaling  modeled  network  parameters,  as  discussed  in  Section  3.6,  this  research  overcame 
the  simulation  run-time  limitations  that  constrained  Stenger's  work.  Another  significant 
result  of  this  research  was  the  analysis  of  an  earth  station's  ability  to  access  the 
IRIDIUM®  network  with  a  degraded  satellite  constellation.  Previous  work  focused  only 
on  the  delay  performance  [Ste96].  The  combination  of  analyzing  the  network  at  high 
loading  levels  and  analyzing  an  earth  station's  ability  to  access  the  network  provided  a 
more  complete  assessment  of  how  the  IRIDIUM®  system  performs  with  a  degraded 
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satellite  constellation.  The  results  of  this  research  are  summarized  in  three  technical 
papers  submitted  for  publication  [FoR98a,  FoR98b,  FoR98c]. 

5.4  Recommendations  for  Future  Research 

There  are  three  primary  areas  in  which  this  research  can  be  expanded.  The  first 
area  is  the  analysis  of  different  non-uniform  traffic  distributions.  This  research  used  a 
non-uniform  traffic  distribution  that  created  a  high  traffic  link  between  two  cities.  The 
significant  impact  that  this  had  on  network  performance  indicates  the  need  to  analyze  the 
effect  of  other  non-uniform  traffic  distributions.  The  next  area  is  the  analysis  of  different 
routing  algorithms.  Since  the  actual  routing  algorithm  of  the  IRIDIUM®  system  is 
unpublished,  this  analysis  used  a  simple  Dijkstra  routing  algorithm.  It  is  likely  that  the 
actual  routing  algorithm  has  the  capability  to  balance  the  network  load  and  route  around 
congested  satellites.  The  significant  effect  that  increasing  the  loading  had  on  network 
performance  indicates  the  need  to  analyze  more  complicated  routing  algorithms.  The 
third  area  is  the  analysis  of  other  LEO  satellite  constellations  such  as  Globalstar. 
Globalstar  uses  fewer  satellites  at  a  higher  altitude  than  the  IRIDIUM®  satellites.  This 
results  in  longer  in-view  times  for  individual  satellites  and  larger  satellite  coverage  areas. 
The  significant  effect  that  non-operational  satellites  had  on  a  user's  ability  to  access  the 
IRIDIUM®  satellite  network  indicates  the  need  to  analyze  other  satellite  constellations  in 
a  similar  manner. 
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APPENDIX 


This  Appendix  contains  the  tabulated  end-to-end  delay  results  and  95% 
confidence  intervals  for  each  test  scenario.  The  results  for  the  Uniform  Low  Load 
scenario  with  a  full  satellite  constellation  and  the  Non-uniform  Medium  Load  scenario 
with  seven  non-operational  satellites  are  presented  in  Section  4.2 


Table  14:  Results  for  Uniform  Low  Load  with  Three  Non-operational  Satellites 


From 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval 

Minimum 

Maximum 

Dhahran 

0.16432 

0.00023 

0.16432 

0.00023 

Melbourne 

0.13837 

0.00028 

0.13837 

0.00028 

0.14688 

0.00042 

0.14688 

0.00042 

0.13480 

0.00143 

0.13480 

0.00143 

Rio 

0.09945 

0.00044 

0.09945 

0.00044 

Berlin 

0.16476 

0.00011 

0.16476 

0.00011 

Table  15:  Results  for  Uniform  Low  Load  with  Five  Non-operational  Satellites 


From 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  I 

Minimum 

Maximum 

Dhahran 

0.16707 

0.00014 

0.16673 

0.16741 

Melbourne 

0.13839 

0.00029 

0.13767 

0.13911 

0.16783 

0.00046 

0.16670 

0.16896 

0.14417 

0.00108 

0.14147 

Rio 

0.12549 

0.00031 

0.12471 

0.12627 

Berlin 

0.17135 

0.00016 

0.17095 

0.17175 
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Table  16:  Results  for  Uniform  Low  Load  with  Seven  N on-operational  Satellites 


From 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  | 

Minimum 

Maximum 

Dhahran 

0.16707 

0.16673 

0.16741 

Melbourne 

0.13839 

0.00029 

0.13767 

0.13911 

0.16783 

0.00046 

0.16670 

0.16896 

0.14417 

0.00108 

1EIEM 

0.14686 

Rio 

0.12549 

0.00031 

0.12471 

0.12627 

Berlin 

0.17135 

0.00016 

0.17095 

0.17175 

Table  17:  Results  for  Uniform  Medium  Load  with  a  Full  Satellite  Constellation 


From 

Kansas 

City  to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  | 

Minimum 

Maximum 

Dhahran 

0.14077 

0.00170 

0.13654 

0.14500 

0.14794 

0.00181 

0.14343 

0.15245 

Beijing 

0.12627 

0.13264 

Eim 

0.15273 

0.00242 

0.14673 

0.15874 

|Rlo 

0.10936 

0.00114 

0.10654 

0.11218 

0.13631 

0.00308 

0.12867 

0.14396 

Table  18:  Results  for  Uniform  Medium  Load  with  Three  N on-operational  Satellites 


From  Kansas 
City  to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  | 

Minimum 

Maximum 

Dhahran 

0.19176 

0.00183 

0.18722 

0.19630 

Melbourne 

0.15984 

0.00167 

0.15569 

0.16400 

EEjinr— 

0.20378 

0.00153 

0.19997 

0.20760 

EESEEUMi 

0.17435 

0.00668" 

0.15775 

0.19095 

Rio 

0.13281 

0.00088 

0.13061 

0.13501 

Berlin 

0.18300 

0.00071 

0.18123 

0.18478 
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Table  19:  Results  for  Uniform  Medium  Load  with  Five  N on-operational  Satellites 


From 

Kansas  City 
to: 

Standard 

Deviation 

95%  Confidence  Interval  i 

Minimum 

Maximum 

Dhahran 

0.20382 

0.00071 

0.20206 

0.20559 

Melbourne 

0.17002 

0.00214 

0.16470 

0.17535 

0.22494 

0.00169 

0.22074 

0.22914 

EJSHHjHI 

0.20104 

0.00072 

0.19926 

0.20282 

Rio 

0.15372 

0.00886 

0.13170 

0.17574 

Berlin 

0.20000 

0.00171 

0.19574 

0.20426 

Table  20:  Results  for  Uniform  Medium  Load  with  Seven  N on-operational  Satellites 


From 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval 

Minimum 

Maximum 

Dhahran 

0.25398 

0.00166 

0.24986 

0.25811 

Melbourne 

0.24036 

0.00427 

0.22975 

0.25097 

innm 

0.27997 

0.00366 

0.28908 

Capetown 

0.26539 

0.00052 

0.26409 

0.26670 

Rio 

0.25556 

0.00897 

0.23327 

0.27784 

Berlin 

0.21303 

0.00124 

0.20994 

■MiMl 

Table  21:  Results  for  Uniform  High  Load  with  a  Full  Satellite  Constellation 


From  Kansas 
City  to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  ! 

Minimum 

Maximum 

Dhahran 

0.17777 

0.00627 

0.16219 

0.19334 

Melbourne 

0.17408 

0.00052 

0.17278 

0.17538 

GEJnmHi 

0.17467 

0.00403 

0.18468 

0.21153 

0.01893 

0.16449 

0.25857 

Rio 

0.12419 

0.00158 

0.12028 

0.12811 

Berlin 

0.17070 

0.00219 

0.16526 

0.17614 
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Table  22:  Results  for  Uniform  High  Load  with  Three  N on-operational  Satellites 


From 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  | 

Minimum 

Maximum 

Dhahran 

0.24435 

0.26063 

Melbourne 

0.17803 

0.00061 

0.17652 

0.17954 

0.19527 

0.00034 

0.19442 

0.19611 

0.22812 

0.00938 

0.20482 

0.25143 

Rio 

0.14062 

0.00234 

0.13480 

0.14645 

Berlin 

0.22388 

0.00099 

0.22142 

0.22633 

Table  23:  Results  for  Uniform  High  Load  with  Five  N on-operational  Satellites 


From 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  | 

Minimum 

Maximum 

Dhahran 

0.25044 

0.00102 

0.24792 

0.25296 

Melbourne 

0.21024 

0.00104 

0.21281 

omich 

0.23334 

0.00150 

0.22963 

0.23705 

Capetown 

0.22812 

0.00454 

0.21684 

0.23940  i 

Rio 

0.15572 

0.00230 

0.14872 

0.16273 

Berlin 

0.22428 

0.00241 

0.21829  | 

0.23027 

Table  24:  Results  for  Uniform  High  Load  with  Seven  N on-operational  Satellites 


From 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  ! 

Minimum 

Maximum 

Dhahran 

0.24272 

0.00480 

0.23080 

0.25464 

Melbourne 

0.23149 

0.00373 

0.22223 

0.24075 

EMEE— 

0.28101 

0.00173 

0.27672 

0.28530 

0.25508 

0.00632 

0.23938 

0.27077 

Rio 

0.23481 

0.00866 

0.21328 

0.25633 

Berlin 

0.22976 

0.00327 

0.22163 

0.23789 
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Table  25:  Results  for  Non-uniform  Low  Load  with  a  Full  Satellite  Constellation 


From 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  j 

Minimum 

Maximum 

Dhahran 

0.14350 

0.00041 

0.14248 

0.14453 

Melbourne 

0.15138 

0.00129 

0.14818 

0.15458 

0.13803 

0.00145 

0.13444 

0.14163 

0.14391 

0.00215 

0.13856 

0.14927 

Rio 

0.11136 

0.00081 

0.10934 

0.11338 

Berlin 

0.15146  ! 

0.00108 

0.14878 

0.15413 

Table  26:  Results  for  Non-uniform  Low  Load  with  Three  N on-operational  Satellites 


From  Kansas 
City  to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  j 

Minimum 

Maximum 

Dhahran 

0.19123 

0.00070 

0.18948 

0.19298 

Melbourne 

0.15892 

0.00101 

0.15640 

0.16144 

0.18706 

0.00167 

0.18290 

0.19122 

0.16531 

0.00197 

0.16042 

0.17020 

Rio 

0.13244 

0.00162 

■IBM 

0.13647 

Berlin 

0.18740 

0.00050 

0.18616 

0.18864 

Table  27:  Results  for  Non-uniform  Low  Load  with  Five  N on-operational  Satellites 


From 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  I 

Minimum 

Maximum 

Dhahran 

0.19378 

0.00158 

0.18985 

0.19770 

Melbourne 

0.16858 

0.00074 

0.16673 

0.17043 

eeiiijEI 

0.20140 

0.00438 

0.19052 

0.21229 

0.17811 

0.00467 

0.16650 

0.18972 

Rio 

0.14772 

0.00147 

0.14406 

0.15137 

Berlin 

0.19794 

0.00096 

0.19555 

0.20033 
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Table  28:  Results  for  Non-uniform  Low  Load  with  Seven  non-operational  Satellites 


From 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  I 

Minimum 

Maximum 

Dhahran 

0.20897 

0.00592 

0.19426 

0.22367 

Melbourne 

0.20904 

0.00770 

0.18991 

0.22816 

unncniHHi 

0.26065 

0.00763 

0.24170 

0.27960 

Capetown 

0.22409 

0.00255 

0.21776 

0.23041 

Rio 

0.23515 

0.00439 

0.22425 

0.24605  i 

Berlin 

0.20268 

0.00151 

0.19894 

0.20643 

Table  29:  Results  for  Non-uniform  Medium  Load  with  a  Full  Satellite  Constellation 


hrom 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  j 

Minimum 

Maximum 

Dhahran 

0.18725 

0.00371 

0.17804 

0.19646 

Melbourne 

0.16924 

0.00038 

0.16829 

0.17019 

nm 

0.00126 

0.20090 

0.16085 

0.00102 

0.15831 

0.16339  . 

Rio 

0.13413 

0.00121 

0.13113 

0.13714 

Berlin 

0.20712 

0.00509 

0.19448 

0.21976 

Table  30:  Results  for  Non-uniform  Medium  Load  with  Three  Non-operational  Satellites 


From  Kansas 
City  to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  ! 

Minimum 

Maximum 

Dhahran 

0.23030 

0.00296 

0.23765 

Melbourne 

0.00081 

0.17141 

0.17544 

EEnmHi 

0.20391 

0.00410 

0.19373 

0.21408 

0.17095 

■eh 

0.16577 

0.17613 

Rio 

0.13716 

0.00259 

0.13073 

0.14360 

Berlin 

0.20636 

0.00084 

0.20427 

0.20844 
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Table  31:  Results  for  Non-uniform  Medium  Load  with  Five  N on-operational  Satellites 


From 

Kansas  City 
to: 

Average 
Sample  Mean 

Standard 

Deviation 

95%  Confidence  Interval  | 

Minimum 

Maximum 

Dhahran 

0.25220 

0.00209 

0.24701 

0.25740 

Melbourne 

0.19768 

0.19546 

0.19989 

inm 

0.24467 

0.00422 

0.23419 

0.25516 

isnssniH 

0.21428 

0.00392 

0.20454 

0.22401 

Rio 

0.16386 

■HI 

0.16048 

0.16724 

Berlin 

0.22183 

0.00123 

0.21877 

0.22489 
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